Cloudflare Launches Application Profiles to Enforce Positive Security on Web Applications

Cloudflare Launches Application Profiles to Enforce Positive Security on Web Applications Cloudflare has introduced Application Profiles, expanding positive security schema learning and validation from APIs to web applications to help reduce attack surfaces against autonomous and prompt-driven threats. Schema Profiles routinely learn expected HTTP request structures, data types, and parameter boundaries from legitimate weekly traffic. Validation operates as an always-on detection layer that populates request metadata, allowing security teams to inspect anomalies before building blocking rules. The feature is available to API Security customers and in closed beta for Enterprise accounts, supporting paths, query parameters, headers, cookies, JSON, and form-encoded bodies. Automated Request Schema Learning Rather than relying exclusively on attack signatures or manual patching, Cloudflare Application Schema Profiles analyze observed traffic to define what expected requests look like. The system learns data types—such as integers, strings, arrays, UUIDs, and short enums—as well as value constraints and character classes. Weekly automated learning runs across zones for operations that have logged at least 1,000 successful 2xx responses over the preceding seven days to identify fields, and at least 10,000 requests to establish boundaries. Profiles update dynamically as traffic evolves, and schemas can be reviewed or exported as OpenAPI v3 files. Traffic Inspection and Flexible Rule Enforcement Once deployed on live traffic, Schema Profiles validate incoming requests without taking automatic action, recommending an initial observation mode to account for application releases or non-malicious client variations. Mismatches are categorized into ten violation reasons and surfaced in Security Analytics. Customers can act on validation metadata by combining fields such as cf.schema_validation.learned.violated or specific parameter-level indicators with Bot Scores and Attack Scores in Security Rules to selectively monitor or block non-conforming requests. LLM Contextualization, Rollout, and Limitations To reduce the operational overhead of managing thousands of endpoints, Cloudflare is applying Workers AI models to contextualize learned profiles, identify relationships between fields, and recommend rate limiting or risk-prioritized mitigations. Currently, Schema Profiles are accessible to existing API Security users and in closed beta for invited Enterprise customers. The system validates query strings, headers, cookies, JSON, and form-encoded payloads, but currently excludes GraphQL, XML, multipart forms, parameter uniqueness enforcement, and mandatory parameter checks.

Cloudflare推出Application Profiles以推行Web应用正面安全策略 Cloudflare正式推出Application Profiles（应用架构配置），将API端成熟的Schema学习与验证拓展至Web应用。该功能通过分析真实流量自动建模正常请求结构，在不依赖已知攻击特征的情况下识别异常，大幅缩减攻击面。 针对LLM带来的自动化新型攻击，正面安全模型通过“仅允许预期结构”限制潜在威胁输入 系统每周基于成功的2xx请求自动学习字段类型与边界，并支持导出OpenAPI规范 违规信号作为请求元数据注入，客户可通过Security Rules结合Bot Score等信号实施阻断 集成Workers AI语义分析与优先级评估，但暂不支持Multipart、GraphQL及XML 正面安全模型与自动学习机制 面对攻击者利用大模型自动化生成载荷与探测系统的挑战，传统依赖已知攻击签名的WAF手段难以全面覆盖。Cloudflare通过分析HTTP请求结构推行正面安全策略。该功能每周自动分析上一周成功的2xx流量，学习字段数据类型及取值边界。一个操作需至少1,000次成功请求来学习字段，至少10,000次来学习数据边界，且生成 Schema 可导出为OpenAPI v3格式。 实时检测与灵活执行策略 配置生成后，系统对实时流量部署常态化检测，将是否偏离模型的结果作为元数据写入请求。检测本身默认不直接拦截，以便用户在Security Analytics中评估影响。用户可在安全规则中使用cf.schema_validation.learned.violated等字段，精确识别违规参数位置或新出现的未声明参数，并与Bot Score、Attack Score联合配置针对性阻断规则。 大模型辅助洞察与功能限制 为降低大规模系统部署的运维复杂度，Cloudflare利用基于Workers AI的LLM分析路径与字段的语义关联，帮助识别凭证和OTP等关键操作并提供防护建议。目前该功能支持路径、查询参数、标头、Cookie以及JSON和表单编码主体，已向拥有API Security的客户开放并启动特邀封测；但当前暂不支持Multipart表单、GraphQL与XML，亦不强制参数唯一性或必需性。

Today, we are launching Application Profiles, a seamless way to enforce a positive security policy. By analyzing the structure and format of HTTP requests and identifying deviations, Cloudflare can help you significantly reduce the attack surface area. Every customer we speak to wants to know how we can protect them from attacks that use frontier AI models. This has become the number one priority for anyone working in security. Large language models (LLMs) allow even non-technical people to launch attacks with a single prompt. LLMs can generate malicious payloads, test known techniques, and probe applications autonomously by mutating their tactics based on the feedback from the application or the Web Application Firewall (WAF). Our tools have changed to stay a step ahead of the attackers. Managed WAF rules and machine learning-based detections remain essential for detecting techniques such as SQL injection, cross-site scripting, remote code execution, and new CVEs, including many variations of those attacks. The answer can’t simply be “patch faster”: this is not sustainable, and it doesn’t work if you haven’t completely mapped your vulnerabilities. What if you could learn what good requests look like by analyzing your traffic structure? Instead of looking only for requests that resemble known attacks, we could allow only requests that conform with what we expect. By doing this, we’d dramatically reduce the attack surface area. For example, if the search field in your query doesn’t expect special characters, we can only accept alphanumeric strings. This would already prevent a vast library of known attacks. But we don’t stop here. Once we have learned the structure and format of your HTTP requests, we can infer the goal of each operation and then understand what the application ultimately does. With this information, we can identify and prioritize the most critical and vulnerable operations and fields you should take care of first. Cloudflare already supports positive security for APIs through Schema Learning and Schema Validation. We are now extending this protection to web applications through [*Application Schema Profiles*](https://developers.cloudflare.com/waf/detections/application-profiles/). You onboard an application, we learn its profile, and then we start to deploy an always-on detection that identifies non-conformity. All automated and enriched by powerful analytics. We are opening a closed beta to invited Enterprise customers without API Security; customers with API Security already have access. Schema Profiles periodically learn the expected request structure from observed traffic. After a profile is available, an *always-on* validation layer is automatically deployed on live traffic. For every request, the detection evaluates whether it conforms or not with the profile, and it adds the result as metadata, augmenting the information already associated with the request. The signal does not take action by itself: customers can analyze past traffic in Security Analytics and decide where enforcement is appropriate and create Security Rules to block non-conforming requests. Requests to operations without a profile are not classified by this feature. Unlike Managed Rules, failing validation does not require a request to match a known attack signature. A value outside an expected range, an unknown enum value, an invalid universally unique identifier (UUID), or unexpected characters — all can be identified because they differ from the learned profile. For example, consider the following operation: `www.example.com/shop/2dbda2e7-cfc9-448d-9465-799d2e6ff363/inventory?product_id=938062541` Below we describe the learning process, which evaluates only the structure and format of the request. When enough traffic has been observed, we learn that the path expects a UUID variable and that `product_id` is an integer and what its boundaries are. When `product_id` contains a string, it will be flagged as a violation. Similarly, Cloudflare can identify malformed UUID values and, when the customer enables enforcement, prevent non-UUID input from reaching the corresponding handler. These simple filters reduce the range of inputs an attacker can send, preventing the vast majority of typical attack vectors, such as SQL injection, cross-site scripting, remote code execution and more. Non-conforming does not always mean malicious. An application release, a new client, or an unusual but valid request may also introduce a difference. We recommend starting in observation mode, so customers can review a profile's effect before enforcement. To determine the anticipated request structure for a web or API application, Schema Profiles routinely analyze observed traffic. Each profile may include the following, depending on the application traffic: For each field, the system learns its data type (integer, string, boolean, arrays, UUID or enum) and constraints such as numeric ranges, short enumerations, string lengths, and character classes. Learning applies to operations that customers select for profiling. In Web Assets, an *operation* is Cloudflare's term for an operation identified by its 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 doesn’t automatically start for discovered operations, while manually created operations do trigger profiling when created. For discovered operations, the customer must intentionally select *Learn profile* from the operation's overflow menu. After profiling is enabled, Cloudflare collects qualifying traffic and runs learning automatically once a week for each zone, using the most recent successful traffic. An operation needs at least 1,000 requests that received a 2xx response in the previous seven days to learn fields, and at least 10,000 to learn data boundaries. Successful requests can include bots and scanners, so customers should review a learned profile before enforcing it. Our roadmap includes allowing customers to trigger learning on demand and excluding automated traffic. Once learned, profiles can be reviewed by selecting *View details* of the operation and finding the learned schema in the *Security overview* panel. If a learned schema is not shown, Cloudflare is still collecting data for the profile. Customers can also export the profile as an OpenAPI v3 schema file. Learned profiles update each week as application traffic changes. New fields are added and fields that are no longer observed are removed, so validation tracks how the application changes. Customers can pin and save the learned schema by downloading the learned schema and uploading it to Schema Validation. Security Analytics now includes a new *Profile Analysis* tab. Customers can select a validation profile and see traffic trends, including how many requests did not conform to the learned profile during the previous seven days. Customers can review the conforming and non-conforming traffic. They can drill into violations and review sampled logs to see where the violation occurred, which field was affected, and why it failed validation. Violations are classified into [ten reasons](https://developers.cloudflare.com/waf/detections/application-profiles/analyze-profile-detections/#understand-violation-details), including type mismatches, values outside a learned range, and invalid formats. Once a team understands the effect, it can use Security Rules to act on the signal. A rule can cover an entire application or be limited to selected paths, operations, or fields. Teams control where to monitor and where to block. Traditional WAF learning modes can build detailed positive-security policies, but they often require operators to review suggestions, stage changes, and maintain policy entities. Cloudflare Schema Profiles expose validation as a request field cf.schema\_validation.learned.violated, allowing customers to combine it with request properties, Bot Score, Attack Score, and other signals in a single Security Rule. By creating simple rules, teams can combine detections and define precisely when Cloudflare should take action. Two other classes of fields are available to create more targeted rules. First, there are fields that collect where the violation occurred. For example, based on our initial example, if the value of `product_id` query parameter does not conform with the profile, the following field will be populated `cf.schema_validation.uploaded.query.violated_parameters = ["product_id"]`. This allows customers to create rules that enforce positive security only on specific fields or exclude them from the enforcement. The second class of field collects new parameters that are not present in the profile. This is useful when you want to handle requests with new parameters (e.g. when deploying a new version of your application), or restrict your posture even further by blocking any parameters that were not detected or defined in the past. | **Use case** | **Field** | **Location values** | **Example** | |---|---|---|---| | Identify where in the request the violation occurred Array up to 20 items | `cf.schema_validation.learned.[location].violated_parameters` | `query,path,headers,cookies,body` | `cf.schema_validation.learned.query.violated_parameters = ["product_id"]` | | Identify whether an undeclared parameter is seen in the request  Array up to 20 items | `cf.schema_validation.learned.[location].undeclared_parameters` | `query` | `cf.schema_validation.learned.query.undeclared_parameters = ["adminMode", "utm"]` | Even with a flexible enforcement design, customers tell us that deploying a positive security policy is operationally complex. A large application can have thousands of operations with tens of thousands of fields. But not all operations and fields carry the same risk. *Contextualization* and *prioritization* helps security teams roll out positive security in a controlled and confident manner. LLMs can help contextualize learned profiles to provide additional insight. For web applications, paths and field names are usually self-explanatory, thus semantic. For example, we piloted running a model hosted on Workers AI across four random applications’ learned profiles. The model successfully identified the link between `clientId` and `account_number` across two applications of a system, as well as the common dependency of using One-Time Password (OTP) for enhanced authentication. Highlighting this context enables security teams to prioritize actions such as configuring Rate Limiting Rules to defend against account-focused brute force attacks. These LLM-powered insights will be accessible directly within the dashboard alongside each operation in [Web Assets](https://developers.cloudflare.com/security/web-assets/). Before executing a one-click deployment, teams can evaluate rule recommendations designed to secure these key fields, backed by mitigation simulation using past traffic to gain confidence. Beyond contextualizing operations with semantic insights and [risk indicators](https://developers.cloudflare.com/api-shield/management-and-monitoring/endpoint-labels/#risk-labels), we are developing additional metrics to order operations using historical request trends and signals. This enables security teams to focus mitigation efforts on the highest-priority operations first, including: Customers with API Security already have access, given that this is an extension of Schema Learning and Schema Validation. We are opening a closed beta to customers without API Security who can test Schema Profiles on production web application traffic, meet with the product team, and provide detailed feedback on profile accuracy, analytics, and enforcement controls. Access is by invitation and does not imply future plan availability. If you are not an API Security customer and want to get access, contact your account team. The feature supports 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 at this time. Schema Profiles validate every value when a parameter name is repeated, but they do not enforce parameter uniqueness. They also do not learn and enforce required parameters or block a request solely because it includes a new parameter. Our idea for Application Profiles does not stop at validating request structure. The same workflow can learn other characteristics of what an application expects (such as ASNs or [JA4s](https://blog.cloudflare.com/ja4-signals/)), explain when traffic deviates from them, and give security teams confidence in defining what “good” looks like. With a Proactive Security workflow, we help security teams get ahead of zero-days!