Cloudflare has launched Application Profiles, a positive security mechanism that learns the expected structure of HTTP requests and flags deviations from that structure. The goal is attack surface reduction: rather than matching requests against known attack signatures, the system admits only traffic that conforms to what the application normally receives.
The company frames this as a response to AI-assisted attacks. LLMs allow even non-technical users to generate malicious payloads, test known techniques, and probe applications autonomously while mutating tactics based on feedback from the application or the WAF. Managed WAF rules and machine learning detections remain in place for SQL injection, cross-site scripting, remote code execution and new CVEs, but patch velocity alone is not treated as a sustainable answer. Cloudflare's argument is that inferring acceptable request shapes from live traffic — for example, accepting only alphanumeric strings in a search field that expects no special characters — removes many known attack paths up front.
How a profile is learned and where it applies
Positive security already existed for APIs through Schema Learning and Schema Validation. Application Schema Profiles extend the same model to web applications: onboard an application, let Cloudflare learn its profile, then run an always-on detection that reports non-conformity. The beta is closed and invitation-based for Enterprise customers without API Security; API Security customers already have access.
Profiles periodically learn the expected request structure from observed traffic. Once a profile exists, validation runs against live traffic and records its verdict as request metadata. The signal alone does not block anything: teams review traffic in Security Analytics, then author Security Rules where enforcement makes sense. Requests to operations without a profile are not classified.
Because validation is based on learned structure rather than signatures, it can flag values outside an expected range, unknown enum values, invalid UUIDs or unexpected characters. A value range, a malformed identifier or an unexpected character class each identifies a request that differs from the profile, even if it matches no known attack pattern. Once enforcement is enabled, those requests can be stopped before reaching the corresponding handler.
A failed validation is not proof of maliciousness. An application release, a new client or an unusual but legitimate request can all cause a deviation, which is why Cloudflare recommends starting in observation mode and reviewing a profile's effect first. The learning process looks only at structure and format.
What gets learned
Depending on application traffic, a profile may cover path variables, query parameters, headers and cookies, and body structure for JSON or form-encoded bodies. For each field the system learns a data type — integer, string, boolean, array, UUID or enum — plus constraints such as numeric ranges, short enumerations, string lengths and character classes.
Learning is limited to operations the customer selects. In Web Assets, an operation is identified by HTTP method, hostname pattern and path pattern. Web Assets continuously discovers operations and lists them under Web Assets > Operations; customers can also add operations manually. Profiling does not start automatically for discovered operations — the customer must select Learn profile from the operation's overflow menu — whereas manually created operations do trigger profiling when created.
Learning runs once a week per zone on the most recent successful traffic. An operation needs at least 1,000 requests that returned a 2xx response in the previous seven days to learn fields, and at least 10,000 to learn data boundaries. Because successful traffic can include bots and scanners, a learned profile should be reviewed before it is enforced. On-demand learning triggers and the ability to exclude automated traffic are on the roadmap.
Learned schemas are visible by selecting View details for an operation and opening the Security overview panel; if no schema appears, collection is still in progress. Profiles can be exported as an OpenAPI v3 schema file. They refresh weekly as traffic changes — new fields are added and unobserved ones are removed — and can be pinned by downloading the schema and uploading it to Schema Validation.
Reviewing traffic before enforcing
Security Analytics adds a Profile Analysis tab, where a validation profile can be selected to see traffic trends over the previous seven days, including the number of requests that did not conform. Teams can separate conforming from non-conforming traffic, drill into violations, and inspect sampled logs showing where the violation occurred, which field was affected and why validation failed. Violations fall into ten reasons, among them type mismatches, values outside a learned range and invalid formats.
Enforcement is expressed through Security Rules, scoped to an entire application or narrowed to selected paths, operations or fields, so teams decide where to monitor and where to block.
Rule building: the available fields
Traditional WAF learning modes can produce detailed positive-security policies, but they typically require operators to review suggestions, stage changes and maintain policy entities. Cloudflare exposes profile validation as the request field cf.schema_validation.learned.violated, which can be combined in a single Security Rule with request properties, Bot Score, Attack Score and other signals.
Two further classes of fields support more targeted rules. Fields that record where a violation occurred name the offending input — if the product_id query parameter fails to conform, cf.schema_validation.uploaded.query.violated_parameters = ["product_id"] is populated, enabling rules that enforce on specific fields or exclude them. A second class captures parameters that are absent from the profile, useful when deploying a new application version or when restricting the posture further by blocking any parameter not previously seen or defined.
Use case | Field | Location values | Example |
|---|---|---|---|
Identify where in the request the violation occurred |
|
|
|
Identify whether an undeclared parameter is seen in the request |
|
|
|
The operational problem: too many fields to review
A large application can contain thousands of operations and tens of thousands of fields, not all carrying equal risk. Cloudflare is working on contextualization and prioritization to let teams roll out positive security in stages.
Semantics help here, since paths and field names in web applications are usually self-explanatory. In a pilot, Cloudflare ran a model hosted on Workers AI across four random applications' learned profiles; the model identified a link between clientId and account_number across two applications of one system, and the shared dependency on One-Time Password (OTP) for stronger authentication. Such context lets teams prioritize actions like configuring Rate Limiting Rules against account-focused brute force attacks. These insights are planned for the dashboard alongside each operation in Web Assets, with rule recommendations that can be evaluated — and mitigation simulated against past traffic — before a one-click deployment.
Cloudflare is also developing metrics to rank operations using historical request trends and signals, so the highest-priority work comes first: data loss (an upward trend of unusual data transfer), reconnaissance activity (a high count of unknown parameters) and business criticality (total traffic volume correlated with unique session IDs served).
Current scope and limitations
API Security customers have access today, since the capability extends Schema Learning and Schema Validation. The closed beta is open to customers without API Security who can test Schema Profiles on production web application traffic, meet the product team and give detailed feedback on profile accuracy, analytics and enforcement controls; access is by invitation and does not imply future plan availability. Non-API-Security customers should contact their account team.
Supported inputs are paths, query parameters, headers, cookies, JSON request bodies and form-encoded request bodies. Profiles can validate integers, strings, UUIDs, arrays and enums containing up to three values. Multipart forms, GraphQL and XML are not supported. Schema Profiles validate every value when a parameter name repeats, but do not enforce parameter uniqueness. They also do not learn or enforce required parameters, and they will not block a request merely for containing a new parameter.
Cloudflare describes the workflow as extensible beyond request structure: the same learning, deviation explanation and confidence-building procedure could cover other expectations such as ASNs or JA4 signals, positioning it as a proactive security workflow aimed at getting ahead of zero-days.
