Cloudflare learns what a good request looks like

Cloudflare has launched Application Profiles, a positive-security feature that learns the structure of an application's HTTP requests and flags the traffic that does not match. The company's pitch is blunt: as frontier AI models make it cheap to generate and vary attack payloads, spotting known bad requests is no longer enough on its own.

Learning what normal looks like

Cloudflare's argument is that managed WAF rules and machine-learning detections still matter. They remain the tool for SQL injection, cross-site scripting, remote code execution and freshly disclosed CVEs. But a large language model lets even a non-technical operator launch an attack from a single prompt, generating payloads, testing known techniques and probing an application autonomously. Patch faster is not a strategy when the attacker can also simply vary the technique.

Application Profiles invert the usual logic. Instead of hunting for requests that resemble known attacks, Schema Profiles learn the expected structure of an application's traffic. Once a profile exists, an always-on validation layer deploys against live traffic and tags every request as conforming or not.

The detection does not need a signature. A value outside an expected range, an unknown enum value, a malformed universally unique identifier or unexpected characters can all be flagged because they differ from what the application normally receives. Cloudflare gives the example of a product identifier that is always an integer: send a string in that field and the request is marked as a violation.

How the profiles are built

Profiles describe body structure for JSON or form-encoded requests, and for each field learn a data type plus constraints such as numeric ranges, short enumerations, string lengths and character classes. Learning applies only to operations a customer selects, and it does not start automatically for discovered ones.

The traffic thresholds are explicit. An operation needs at least 1,000 requests that received a 2xx response over the previous seven days before Cloudflare will learn its fields, and at least 10,000 before it will learn data boundaries. Learning then reruns weekly using the most recent successful traffic, so new fields are added and abandoned ones are dropped. Cloudflare warns that successful requests can include bots and scanners, so customers should check what the profile absorbed rather than trusting it as a description of genuine user behaviour.

Learned schemas can be reviewed in a Security overview panel, exported as an OpenAPI v3 file and pinned so that the schema stops drifting. A new Profile Analysis tab in Security Analytics shows traffic trends, lets teams drill into individual violations and classifies them into ten reasons, including type mismatches, values outside a learned range and invalid formats.

Enforcement runs through Security Rules. The signal arrives as the request field cf.schema_validation.learned.violated, which can be combined with request properties, Bot Score and Attack Score in a single rule, scoped to a whole application or narrowed to selected paths, operations or fields. Two further classes of field record where a violation occurred and which parameters were undeclared, so a team can block anything the profile has never seen before.

Non-conforming traffic is not automatically malicious. An application release, a new client or an unusual but valid request can all introduce a legitimate difference, which is why Cloudflare recommends starting in observation mode and reviewing a profile's effect before enforcing it.

The limits are stated plainly. Application Profiles cover paths, query parameters, headers, cookies, JSON bodies and form-encoded bodies, and can validate integers, strings, UUIDs, arrays and enums of up to three values. Multipart forms, GraphQL and XML are not supported yet, and profiles do not learn required parameters or block a request purely for carrying a new one. Customers with API Security already have access, since the feature extends Cloudflare's existing Schema Learning and Schema Validation; everyone else can apply to a closed beta for Enterprise accounts, by invitation.

Cloudflare also trails what comes next. It is piloting a model hosted on Workers AI to read learned profiles and explain what an application does, surfacing linked fields and risk indicators next to each operation, with rule recommendations and mitigation simulation drawn from historical traffic.

Our opinion

Cloudflare is selling a change of temperament rather than a new detection engine. Security teams have spent a decade in a reactive posture, buying signature feeds and racing patch windows. Allow-listing what an application is willing to accept is an old idea, and it is one that operations teams have historically rejected, because strict validation breaks things at the worst possible moment. What Cloudflare is actually offering is the missing piece that made positive security unattractive: a profile derived automatically from real traffic, with an observation mode and violation analytics, so nobody has to hand-write the schema.

The honest caveat is the traffic thresholds and the weekly relearning. A profile learned from 1,000 requests is a coarse description of an application, and one that quietly reshapes itself every week can drift into accepting exactly the traffic an attacker is sending, one small increment at a time. Pinning the schema solves that, but it also returns the maintenance burden that made allow-listing unpopular. Application Profiles will earn their reputation in the hands of teams that treat the profile as something to review, not something to trust.