TL;DR
- Application Profiles learns the expected structure of HTTP requests by analyzing traffic, then validates all incoming requests against that learned profile
- The system identifies deviations in paths, query parameters, headers, cookies, request bodies, and data types (integers, strings, booleans, arrays, UUIDs, enums) without requiring signature matching
- Validation enriches requests with metadata that customers can review in Security Analytics before creating rules to block non-conforming traffic
- A closed beta is available to Enterprise customers without API Security; existing API Security customers already have access
- Availability
- Closed beta for Enterprise
- Request elements
- Paths, query parameters
- Data types learned
- Integer, string, boolean
What happened
Cloudflare announced Application Profiles, a positive security feature that learns the expected structure and format of HTTP requests to web applications. Rather than looking for patterns matching known attacks, the system allows only requests that conform to learned application behavior. This approach aims to dramatically reduce attack surface by rejecting malformed or unexpected inputs before they reach the application.
How profiles are built and used
Application Profiles continuously analyze observed traffic to understand what legitimate requests look like. The system learns the expected structure for paths, query parameters, headers and cookies, and request body structure (both JSON and form-encoded). For each field, it determines the data type and constraints such as numeric ranges, string lengths, and character classes. An operation needs at least 1,000 requests with 2xx responses in the previous seven days to learn fields, and 10,000 requests to learn data boundaries. Profiles update weekly as application traffic changes, with new fields added and unused fields removed.
After a profile is available, an always-on validation layer automatically deploys on live traffic. For every request, the system evaluates conformance and adds the result as metadata. Unlike Managed Rules, validation does not require matching a known attack signature. A value outside an expected range, an unknown enum value, an invalid UUID, or unexpected characters all trigger detection because they differ from the learned profile.
Customers can review profiles directly in the dashboard or export them as OpenAPI v3 schema files. The validation does not take action by itself; customers first review traffic patterns in Security Analytics to understand the profile's effect before creating Security Rules to enforce blocking.
Understanding validation results
Security Analytics now includes a Profile Analysis tab showing traffic trends and how many requests did not conform during the previous seven days. Customers can drill into violations and see sampled logs identifying which field was affected and why it failed validation. Violations are classified into ten reasons, including type mismatches, values outside learned ranges, and invalid formats.
The validation exposes results as request fields that can be combined in Security Rules. The field cf.schema_validation.learned.violated indicates any non-conformity. Additional fields identify where violations occurred (cf.schema_validation.learned.[location].violated_parameters) and detect new parameters not present in the profile (cf.schema_validation.learned.[location].undeclared_parameters). This granular metadata lets teams create rules that enforce positive security only on specific fields or exclude them from enforcement.
Starting in observation mode is recommended, as non-conforming requests may result from legitimate application changes, new clients, or valid edge cases. Customers can review a profile's effect before enforcement to avoid blocking legitimate traffic.
Future enhancements
Cloudflare plans to add critical field analysis powered by Large Language Models to help teams prioritize which operations and fields require protection first. An LLM pilot across four applications successfully identified semantic links between fields like clientId and account_number, and recognized dependencies such as One-Time Password use for authentication. These insights will appear in the dashboard alongside each operation, with rule recommendations and mitigation simulation using past traffic to build confidence before deployment.
The roadmap also includes metrics to prioritize operations by data loss trends, reconnaissance activity, and business criticality based on traffic volume and unique session counts. This contextualization helps security teams focus mitigation efforts on the highest-risk operations first.
Availability and scope
Customers with existing API Security already have access, as Application Profiles extends Schema Learning and Schema Validation. A closed beta is opening to Enterprise customers without API Security. Access requires invitation and does not imply future plan availability.
The feature currently supports paths, query parameters, headers, cookies, JSON request bodies, and form-encoded request bodies. Profiles validate integers, strings, UUIDs, arrays, and enums containing up to three values. Multipart forms, GraphQL, and XML are not supported. Profile validation does not enforce parameter uniqueness, learn and enforce required parameters, or block requests solely because they include a new parameter. Profiling does not automatically start for discovered operations; customers must intentionally select 'Learn profile' from the operation's menu. Manually created operations trigger profiling when created.
Source
Cloudflare Bloghttps://blog.cloudflare.com/application-profiles/AI-assisted, verified against the source. This post was drafted with AI from the primary source linked above and checked automatically against it. For anything you depend on, read the original.
- #webapplicationsecurity
- #positivesecurity
- #apisecurity
- #attacksurface
- #cloudflare



