diff --git a/src/content/docs/waf/account/index.mdx b/src/content/docs/waf/account/index.mdx index 68a9b4150f6249..5ccb24458bc092 100644 --- a/src/content/docs/waf/account/index.mdx +++ b/src/content/docs/waf/account/index.mdx @@ -11,9 +11,9 @@ sidebar: This feature requires an Enterprise plan. ::: -The account-level Web Application Firewall (WAF) configuration allows you to define a configuration once and apply it to multiple Enterprise zones in your account. +The account-level Web Application Firewall (WAF) configuration allows you to define a configuration once and apply it to multiple Enterprise zones in your account. Instead of configuring each zone individually, you create rulesets at the account level and use expressions to control which zones and traffic they apply to. -Configure and deploy custom rulesets, rate limiting rulesets, and managed rulesets to multiple Enterprise zones, affecting all incoming traffic or only a subset (for example, all traffic to `/admin/*` URI paths in both `example.com` and `example.net`). +For example, you can deploy a single ruleset that applies to `/admin/*` URI paths across both `example.com` and `example.net`. Rulesets can target all incoming traffic or a specific subset. At the account level, WAF rules are grouped into rulesets. You can perform the following operations: diff --git a/src/content/docs/waf/account/managed-rulesets/index.mdx b/src/content/docs/waf/account/managed-rulesets/index.mdx index b1df3d9873a4db..2a9612a873ffd7 100644 --- a/src/content/docs/waf/account/managed-rulesets/index.mdx +++ b/src/content/docs/waf/account/managed-rulesets/index.mdx @@ -15,13 +15,13 @@ This feature requires an Enterprise plan. ## Account-level deployment -At the account level, you can deploy each [WAF managed ruleset](/waf/managed-rules/#available-managed-rulesets) more than once. This means that you can apply the same managed ruleset with different configurations to different subsets of incoming traffic for the Enterprise zones in your account. +At the zone level, each [WAF managed ruleset](/waf/managed-rules/#available-managed-rulesets) can only be deployed once. At the account level, you can deploy each managed ruleset more than once. This allows you to apply the same ruleset with different configurations to different subsets of incoming traffic across the Enterprise zones in your account. -For example, you could deploy the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times with different paranoia levels and a different action (_Managed Challenge_ action for PL3 and _Log_ action for PL4). +For example, you could deploy the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times with different [paranoia levels](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#paranoia-level) and a different action (_Managed Challenge_ action for PL3 and _Log_ action for PL4). Higher paranoia levels enable additional rules that are more likely to produce false positives.
-The following example deploys the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times at the account level through the following execute rules: +The following example deploys the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times at the account level through the following [execute rules](/ruleset-engine/managed-rulesets/deploy-managed-ruleset/): - First execute rule: Enable OWASP rules up to paranoia level 3 (PL3) and set the action to _Managed Challenge_. - Second execute rule: Enable OWASP rules up to PL4 and set the action to _Log_. @@ -48,7 +48,7 @@ Once you finish your configuration, the **Deployed managed rulesets** list will -The following `POST` request for the [Create an account ruleset](/api/resources/rulesets/methods/create/) operation creates an [entry point ruleset](/ruleset-engine/about/rulesets/#entry-point-ruleset) for the `http_request_firewall_managed` phase at the account level. The ruleset includes two rules deploying the Cloudflare OWASP Core Ruleset twice with different configurations. +The following `POST` request for the [Create an account ruleset](/api/resources/rulesets/methods/create/) operation creates an [entry point ruleset](/ruleset-engine/about/rulesets/#entry-point-ruleset) for the `http_request_firewall_managed` [phase](/ruleset-engine/about/phases/) at the account level. The ruleset includes two rules deploying the Cloudflare OWASP Core Ruleset twice with different configurations. rate limit for requests matching an expression, and the action to perform when that rate limit is reached. At the account level, rate limiting rules are always grouped into rate limiting rulesets, which you then deploy. +[Rate limiting rules](/waf/rate-limiting-rules/) allow you to define a rate limit for requests matching an [expression](/ruleset-engine/rules-language/expressions/), and the action to perform when that rate limit is reached. You can configure rate limiting rules for a single zone or at the account level. + +Account-level rate limiting rulesets allow you to define rate limiting rules once and deploy them to multiple Enterprise zones. Instead of configuring the same rules in each zone, you create a ruleset at the account level and control which zones it applies to. :::note This feature requires an Enterprise plan. ::: -To apply a rate limiting ruleset at the account level, create a custom rate limiting ruleset with one or more [rate limiting rules](/waf/rate-limiting-rules/), and then deploy it to one or more zones on an Enterprise plan. +To apply a rate limiting ruleset at the account level: + +1. Create a rate limiting ruleset with one or more rate limiting rules. +2. Deploy the ruleset to one or more zones on an Enterprise plan. For more information on how Cloudflare calculates request rates, refer to [Request rate calculation](/waf/rate-limiting-rules/request-rate/). diff --git a/src/content/docs/waf/analytics/security-analytics.mdx b/src/content/docs/waf/analytics/security-analytics.mdx index 0ff0e799383029..8bf3eb4c8ac19b 100644 --- a/src/content/docs/waf/analytics/security-analytics.mdx +++ b/src/content/docs/waf/analytics/security-analytics.mdx @@ -14,20 +14,20 @@ import { Render, } from "~/components"; -Security Analytics displays information about all incoming HTTP requests for your domain, including requests not handled by Cloudflare security products. +Security Analytics displays information about all incoming HTTP requests for your domain, including requests not handled by Cloudflare security products. This gives you visibility into your full traffic profile, not only the requests that triggered a security rule. -By default, Security Analytics queries filter on `requestSource = 'eyeball'`, which represents requests from end users. Note that requests from Cloudflare Workers (subrequests) are not visible in Security Analytics. +By default, Security Analytics shows requests from end users (requests to your site directly, as opposed to requests generated by Cloudflare products). Requests generated by [Cloudflare Workers](/workers/) subrequests are not included. Use the Security Analytics dashboard to: - View the traffic distribution for your domain. -- Understand which traffic is being mitigated by Cloudflare security products, and where non-mitigated traffic is being served from (Cloudflare global network or [origin server](https://www.cloudflare.com/learning/cdn/glossary/origin-server/)). +- Understand which traffic is being mitigated by Cloudflare security products, and where non-mitigated traffic is being served from (Cloudflare global network or [origin server](https://www.cloudflare.com/learning/cdn/glossary/origin-server/)). - Analyze suspicious traffic and create tailored WAF custom rules based on applied filters. -- Learn more about Cloudflare's security scores (attack score, [bot score](/bots/concepts/bot-score/), [malicious uploads](/waf/detections/malicious-uploads/), and [leaked credentials](/waf/detections/leaked-credentials/) results) with real data. +- Review Cloudflare's security scores (attack score, [bot score](/bots/concepts/bot-score/), [malicious uploads](/waf/detections/malicious-uploads/), and [leaked credentials](/waf/detections/leaked-credentials/) results) with real data from your traffic. - [Find an appropriate rate limit](/waf/rate-limiting-rules/find-rate-limit/) for incoming traffic. - Analyze suspicious traffic ([new security dashboard](/security/) only). -If you need to modify existing security-related rules you already configured, consider also checking [Security Events](/waf/analytics/security-events/). This dashboard displays information about requests affected by Cloudflare security products. +Security Analytics shows all traffic, whether or not Cloudflare acted on it. If you are looking for requests that Cloudflare security products acted on or flagged, refer to [Security Events](/waf/analytics/security-events/) instead. ## Availability @@ -113,7 +113,7 @@ Each suspicious activity is classified with a severity score that can vary from The main chart displays the following data for the selected time frame, according to the selected tab: - **Traffic analysis**: Traffic mitigated by the Cloudflare security platform, served by Cloudflare, and served by the origin server, according to the following classification: - - **Mitigated by WAF**: Requests blocked or challenged by Cloudflare's application security products such as the WAF and HTTP DDoS protection. It does not include requests that had the following actions applied: _Log_, _Skip_, and _Allow_. + - **Mitigated by WAF**: Requests blocked or [challenged](/cloudflare-challenges/challenge-types/challenge-pages/#actions) by Cloudflare's application security products such as the WAF and HTTP DDoS protection. Requests with _Log_, _Skip_, or _Allow_ [actions](/ruleset-engine/rules-language/actions/) are not counted as mitigated. - **Served by Cloudflare**: Requests served by the Cloudflare global network such as cached content and redirects. - **Served by origin**: Requests served by your origin server. @@ -155,7 +155,12 @@ To apply the filters for an insight to the data displayed in the Security Analyt Only available in the previous dashboard navigation structure. ::: -The **Attack analysis**, **Bot analysis**, **Malicious uploads**, and **Account abuse detection** sections display statistics related to WAF attack scores, bot scores, WAF content scanning scores, and leaked credentials scanning of incoming requests for the selected time frame. All plans include access to the **Leaked credential check** under **Account abuse detection**. This feature detects login attempts using credentials that have been exposed online. For more information on what to do if you have credentials that have been leaked, refer to [Example mitigation rules](/waf/detections/leaked-credentials/examples/). +The **Attack analysis**, **Bot analysis**, **Malicious uploads**, and **Account abuse detection** sections display statistics related to Cloudflare's security scores for incoming requests in the selected time frame: + +- **Attack analysis**: Uses [WAF attack scores](/waf/detections/attack-score/) to classify requests based on the likelihood that the request is malicious. +- **Bot analysis**: Uses [bot scores](/bots/concepts/bot-score/) to classify requests based on the likelihood they come from automated traffic. +- **Malicious uploads**: Uses [WAF content scanning](/waf/detections/malicious-uploads/) scores to detect potentially malicious content uploaded in requests. +- **Account abuse detection**: Uses [leaked credentials detection](/waf/detections/leaked-credentials/) to identify login attempts with credentials that have been exposed in data breaches. All plans include access to the **Leaked credential check** under this section. For more information on what to do if you have leaked credentials, refer to [Example mitigation rules](/waf/detections/leaked-credentials/examples/). You can examine different traffic segments according to the current metric (attack score, bot score, or content scanning). To apply score filters for different segments, select the buttons below the traffic chart. For example, select **Likely attack** under **Attack analysis** to filter requests that are likely an attack (requests with WAF attack score values between 21 and 50). @@ -165,7 +170,7 @@ Additionally, you can use the slider tool below the chart to filter incoming req Security Analytics shows request logs for the selected time frame and applied filters, along with detailed information and security analyses of those requests. -By default, Security Analytics uses sampled logs for the logs table. If you are subscribed to [Log Explorer](/log-explorer/), you may also have access to [raw logs](#raw-logs). +By default, Security Analytics uses sampled logs (a subset of your traffic rather than every individual request). Sampling allows Cloudflare to return results in seconds, even when query volumes are large. If you are subscribed to [Log Explorer](/log-explorer/), you may also have access to [raw logs](#raw-logs). #### Sampled logs @@ -208,4 +213,4 @@ Currently, changing the time frame or the applied filters while showing raw logs ## Sampling -The Security Analytics dashboard uses [sampled data](/analytics/graphql-api/sampling/), except when showing raw logs. Most information in the dashboard is obtained from `httpRequestsAdaptiveGroups` and `httpRequestsAdaptive` GraphQL nodes. For more information on working directly with GraphQL datasets, refer to [Datasets (tables)](/analytics/graphql-api/features/data-sets/). +The Security Analytics dashboard uses [sampled data](/analytics/graphql-api/sampling/), except when showing raw logs. If you query Security Analytics data through the [GraphQL Analytics API](/analytics/graphql-api/), the primary underlying datasets are `httpRequestsAdaptiveGroups` and `httpRequestsAdaptive`. For more information, refer to [Datasets (tables)](/analytics/graphql-api/features/data-sets/). diff --git a/src/content/docs/waf/analytics/security-events.mdx b/src/content/docs/waf/analytics/security-events.mdx index a11a2cbdba429b..0d9ac32eada277 100644 --- a/src/content/docs/waf/analytics/security-events.mdx +++ b/src/content/docs/waf/analytics/security-events.mdx @@ -14,7 +14,9 @@ import { DashButton, } from "~/components"; -Security Events allows you to review mitigated requests and helps you tailor your security configurations. +Security Events allows you to review mitigated requests and helps you tailor your security configurations. Use Security Events to investigate requests that Cloudflare security products acted on or flagged, identify false positives, and fine-tune your security rules. + +If you want to analyze all incoming traffic, including requests that Cloudflare did not act on, refer to [Security Analytics](/waf/analytics/security-analytics/) instead. The main elements of the dashboard are the following: @@ -23,7 +25,7 @@ The main elements of the dashboard are the following: - [Top events by source](#top-events-by-source): Provides details of the traffic flagged or actioned by a Cloudflare security feature (for example, IP addresses, User Agents, Paths, Countries, Hosts, ASNs). - [Sampled logs](#sampled-logs): Summarizes security events by date to show the action taken and the applied Cloudflare security product. -Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as [Browser Integrity Check](/waf/tools/browser-integrity-check/). Each incoming HTTP request might generate one or more security events. The Security Events dashboard only shows these events, not the HTTP requests themselves. +Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as [Browser Integrity Check](/waf/tools/browser-integrity-check/). A single HTTP request can generate one or more security events when it triggers security features. The Security Events dashboard shows these individual events, not the HTTP requests themselves. ## Availability @@ -68,7 +70,7 @@ To manually add a filter: 1. Select **Add filter**. -2. Select a field, an operator, and a value. For example, to filter events by IP address, select _IP_ for **Action**, select _equals_ for the operator, and enter the IP address. +2. Select a field, an operator, and a value. For example, to filter events by IP address, select _IP_ for the field, select _equals_ for the operator, and enter the IP address. 3. Select **Apply**. @@ -118,7 +120,7 @@ A deleted custom rule or rate limiting rule will show as `Rule unavailable` unde ## Sampled logs -**Sampled logs** summarizes security events by date to show the action taken and the applied Cloudflare security feature. +**Sampled logs** shows a subset of security events for the selected time period, listed by date with the action taken and the applied Cloudflare security feature. For large volumes of traffic, Cloudflare uses [sampling](/analytics/graphql-api/sampling/) to return results faster. This means that not every individual event may appear in the list. ![Example list of events in Sampled logs, with one of the events expanded to show its details](~/assets/images/waf/events-sampled-logs.png) @@ -174,8 +176,8 @@ The generated report will reflect all applied filters. Security Events currently has these limitations: -- Security Events may use sampled data to improve performance. If your search uses sampled data, Security Events might not display all events and filters might not return the expected results. To display more events, select a smaller time frame. +- Security Events may use sampled data to improve performance. If your search uses sampled data, Security Events might not display all events and filters might not return the expected results. To display more events, select a smaller time frame (a narrower time range reduces the volume of data, which reduces or eliminates sampling). - The Cloudflare dashboard may show an inaccurate number of events per page. Data queries are highly optimized, but this means that pagination may not always work because the source data may have been sampled. The GraphQL Analytics API does not have this pagination issue. -- Triggered OWASP rules appear in the Security Events page under **Additional logs**, but they are not included in exported JSON files. +- Triggered [OWASP rules](/waf/managed-rules/reference/owasp-core-ruleset/) appear in the Security Events page under **Additional logs**, but they are not included in exported JSON files. diff --git a/src/content/docs/waf/change-log/index.mdx b/src/content/docs/waf/change-log/index.mdx index b8050d9a4d467d..242f2dddc9c74e 100644 --- a/src/content/docs/waf/change-log/index.mdx +++ b/src/content/docs/waf/change-log/index.mdx @@ -12,7 +12,7 @@ head: import { LinkButton, RSSButton } from "~/components"; -The [WAF changelog](/waf/change-log/changelog/) provides information about changes to managed rulesets and general updates to WAF protection. +The [WAF changelog](/waf/change-log/changelog/) provides information about changes to [managed rulesets](/waf/managed-rules/) and general updates to WAF protection. View changelog @@ -24,20 +24,32 @@ The [WAF changelog](/waf/change-log/changelog/) provides information about chang ## Changelog for managed rulesets -Cloudflare has a regular cadence of releasing updates and new rules to WAF managed rulesets. The updates either improve a rule's accuracy, lower false positives rates, or increase the protection due to a change in the threat landscape. +Cloudflare regularly releases updates and adds new rules to WAF [managed rulesets](/waf/managed-rules/). Updates improve rule accuracy, reduce false positives, or increase protection in response to changes in the threat landscape. -The release cycle for new rules happens on a 7-day cycle, typically every Monday or Tuesday depending on public holidays. For updates of existing rules, Cloudflare will initially deploy the updated rule as a `BETA` rule (denoted in rule description) and with a `beta` tag, before updating the original rule on the next release cycle. Cloudflare will deploy the updated or new rules into logging only mode (_Log_ action), with `beta` and `new` tags. Most newly created rules will carry both the `beta` and `new` tags. Logging only mode allows you to identify any increases in security event volumes which look like potential false positives. On the following Monday (or Tuesday) the rules will change from logging only mode to the intended default action (**New Action** column in the changelog table), with the `beta` and `new` tags removed. +### Release cycle -Cloudflare may also add rules on the same 7-day release cycle in disabled mode to make the remediation logic available to customers, who can activate the rule if needed. Having these rules in place allows Cloudflare to perform impact testing and performance checks without affecting traffic. These deactivated rules will not have the `beta` and `new` tags assigned to them. +New and updated rules follow a seven-day release cycle, typically on Monday or Tuesday (adjusted for public holidays). -Cloudflare is very proactive in responding to new vulnerabilities, which may need to be released outside of the 7-day cycle, defined as an Emergency Release. +**Week 1 — Logging only:** Cloudflare deploys new or updated rules in logging-only mode with the _Log_ action. Rules in this mode record matching requests but do not block traffic. Most newly created rules carry both the `beta` and `new` tags. Use this period to review your security events for unexpected matches that could be false positives. + +**Week 2 — Default action:** On the following release day, the rules change from the _Log_ action to their intended default action (shown in the **New Action** column of the changelog table). The `beta` and `new` tags are removed. + +For updates to existing rules, Cloudflare first deploys the updated version as a separate `BETA` rule (noted in the rule description) with a `beta` tag, before updating the original rule on the next release cycle. + +### Disabled rules + +Cloudflare may also add rules in disabled mode on the same release cycle. These rules make remediation logic available without affecting traffic, and allow Cloudflare to perform impact testing and performance checks. You can activate a disabled rule at any time if you need its protection. Disabled rules do not carry the `beta` or `new` tags. + +### Emergency releases + +For new vulnerabilities, Cloudflare may release rules outside the regular seven-day cycle. These are emergency releases. :::caution -[Ruleset overrides and tag overrides](/ruleset-engine/managed-rulesets/override-managed-ruleset/) apply to existing and **future** rules in the managed ruleset, which includes changes in regular and emergency releases. +[Ruleset overrides and tag overrides](/ruleset-engine/managed-rulesets/override-managed-ruleset/) apply to existing and **future** rules in a managed ruleset. This means overrides you configure today will automatically apply to rules added in regular and emergency releases. ::: -If you do notice a new or updated rule generating an increased volume of security events, you can disable or change the rule from its _Default_ action. Once you change a rule to use an action other than the default one, Cloudflare will not be able to override the rule action. +If you notice a new or updated rule generating an increased volume of security events, you can disable it or change its action from the default. Once you change a rule to use an action other than the default one, Cloudflare will not be able to override the rule action. ## General updates -The [changelog](/waf/change-log/changelog/) also includes more general updates to WAF protection. +The [changelog](/waf/change-log/changelog/) also includes general updates to WAF protection that are not specific to managed rulesets. diff --git a/src/content/docs/waf/custom-rules/custom-rulesets.mdx b/src/content/docs/waf/custom-rules/custom-rulesets.mdx index 8b1e960ee98d2f..a91449614ab637 100644 --- a/src/content/docs/waf/custom-rules/custom-rulesets.mdx +++ b/src/content/docs/waf/custom-rules/custom-rulesets.mdx @@ -20,10 +20,12 @@ Consider creating custom rulesets instead of managing individual custom rules at Currently, the Cloudflare dashboard does not support working with custom rulesets at the zone level. You will need to use the Cloudflare API to configure or deploy these rulesets. ::: +Creating a custom ruleset does not activate it. Custom rulesets only run when a rule with the `execute` action references them from a [phase entry point ruleset](/ruleset-engine/about/rulesets/#entry-point-ruleset) — the top-level ruleset that Cloudflare evaluates for each request in a given [phase](/ruleset-engine/about/phases/). + To deploy a custom ruleset for a zone: 1. Create a custom ruleset at the zone level with one or more rules. Alternatively, identify the existing custom ruleset you want to deploy using the [List zone rulesets](/api/resources/rulesets/methods/list/) API operation. -2. Deploy the custom ruleset so that it gets executed. To deploy a custom ruleset, create a rule with the `execute` action. +2. Add a rule with the `execute` action to the `http_request_firewall_custom` phase entry point ruleset, referencing the custom ruleset ID. This rule tells Cloudflare to run the custom ruleset when the rule expression matches. ### 1. Create custom ruleset @@ -220,7 +222,7 @@ Deploy the custom ruleset by adding a rule with `"action": "execute"` to the `ht ## Next steps -Use the different operations in the [Rulesets API](/ruleset-engine/rulesets-api/) to work with the custom ruleset you created and deployed. The following table has a list of common tasks for working with custom rulesets at the account level: +Use the different operations in the [Rulesets API](/ruleset-engine/rulesets-api/) to work with the custom ruleset you created and deployed. The following table has a list of common tasks for working with custom rulesets at the zone level: | Task | Procedure | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | diff --git a/src/content/docs/waf/custom-rules/index.mdx b/src/content/docs/waf/custom-rules/index.mdx index 3c0b91ffe23fad..3695c7c6ea7c5b 100644 --- a/src/content/docs/waf/custom-rules/index.mdx +++ b/src/content/docs/waf/custom-rules/index.mdx @@ -9,7 +9,7 @@ import { Render, FeatureTable } from "~/components"; -Custom rules are evaluated in order, and some actions like _Block_ will stop the evaluation of other rules. For more details on actions and their behavior, refer to [Actions](/ruleset-engine/rules-language/actions/). +Custom rules are evaluated in order, and some actions like _Block_ will stop the evaluation of other rules. This means that if an earlier rule blocks a request, later rules will not run for that request. For more details on actions and their behavior, refer to [Actions](/ruleset-engine/rules-language/actions/). ## Custom rulesets @@ -27,7 +27,7 @@ Currently, the Cloudflare dashboard does not support working with custom ruleset -The maximum number of custom rules applies to an entire [phase](/ruleset-engine/about/phases/). Each scope (zone or account) has a separate maximum number of rules, counted in the following way: +The maximum number of custom rules applies to all rules in the `http_request_firewall_custom` [phase](/ruleset-engine/about/phases/), which is where custom rules run. Each scope (zone or account) has a separate maximum number of rules, counted in the following way: - Zone: All custom rules plus all the rules across custom rulesets defined at the zone level. - Account: All the rules across custom rulesets defined at the account level. diff --git a/src/content/docs/waf/managed-rules/index.mdx b/src/content/docs/waf/managed-rules/index.mdx index 71098757f43ae3..f0229454e24579 100644 --- a/src/content/docs/waf/managed-rules/index.mdx +++ b/src/content/docs/waf/managed-rules/index.mdx @@ -16,13 +16,13 @@ import { FeatureTable, Render, RuleID } from "~/components"; ## Available managed rulesets -- [**Cloudflare Managed Ruleset**](/waf/managed-rules/reference/cloudflare-managed-ruleset/): Created by the Cloudflare security team, this ruleset provides fast and effective protection for all of your applications. The ruleset is updated frequently to cover new vulnerabilities and reduce false positives.
Ruleset ID: +- [**Cloudflare Managed Ruleset**](/waf/managed-rules/reference/cloudflare-managed-ruleset/): Created by the Cloudflare security team, this ruleset provides fast and effective protection for all of your applications. It covers known attack techniques and zero-day vulnerabilities (newly discovered flaws with no available patch). The ruleset is updated frequently to address new threats and reduce false positives (legitimate requests incorrectly flagged).
Ruleset ID: -- [**Cloudflare OWASP Core Ruleset**](/waf/managed-rules/reference/owasp-core-ruleset/): Cloudflare's implementation of the Open Web Application Security Project, or OWASP ModSecurity Core Rule Set. Cloudflare routinely monitors for updates from OWASP based on the latest version available from the official code repository.
Ruleset ID: +- [**Cloudflare OWASP Core Ruleset**](/waf/managed-rules/reference/owasp-core-ruleset/): Cloudflare's implementation of the Open Web Application Security Project (OWASP) ModSecurity Core Rule Set. This ruleset uses a scoring model — each matching rule adds its score to a cumulative [threat score](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#request-threat-score), and the WAF executes the configured action when the score exceeds the [threshold](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#score-threshold).
Ruleset ID: -- [**Cloudflare Exposed Credentials Check**](/waf/managed-rules/reference/exposed-credentials-check/): Deploy an automated credentials check on your end-user authentication endpoints. For any credential pair, the Cloudflare WAF performs a lookup against a public database of stolen credentials. Cloudflare recommends that you use [leaked credentials detection](/waf/detections/leaked-credentials/) instead of this ruleset.
Ruleset ID: +- [**Cloudflare Exposed Credentials Check**](/waf/managed-rules/reference/exposed-credentials-check/): Deploys an automated credentials check on your end-user authentication endpoints. For any credential pair, the Cloudflare WAF performs a lookup against a public database of stolen credentials to determine if they were previously compromised. Cloudflare recommends that you use [leaked credentials detection](/waf/detections/leaked-credentials/) instead of this ruleset.
Ruleset ID: -- **Cloudflare Free Managed Ruleset**: Available on all Cloudflare plans. Designed to provide mitigation against high and wide impacting vulnerabilities. The rules are safe to deploy on most applications. If you deployed the Cloudflare Managed Ruleset for your site, you do not need to deploy this managed ruleset.
Ruleset ID: +- **Cloudflare Free Managed Ruleset**: Available on all Cloudflare plans. Provides protection against high-impact and widely exploited vulnerabilities. The rules are safe to deploy on most applications. If you have already deployed the Cloudflare Managed Ruleset, you do not need this ruleset — the Cloudflare Managed Ruleset includes broader coverage.
Ruleset ID: The following managed rulesets run in a response phase: @@ -51,16 +51,16 @@ The managed rulesets you can deploy depend on your Cloudflare plan. ### Maximum body size -Cloudflare analyzes the body of incoming requests up to a certain maximum size that varies according to your Cloudflare plan: +Managed rules inspect the body of each incoming request up to a maximum size. This limit varies by plan: - For Enterprise customers, the maximum body size is 128 KB. -- For other paid plans, the limit is lower by default — reach out to your account team or to Cloudflare Support to increase the limit. +- For other paid plans, the limit is lower by default — contact your account team or Cloudflare Support to increase the limit. - For users in the Free plan, the limit is 1 MB. -This means that the behavior of specific managed rules that analyze request bodies can vary according to your current plan. For example, the OWASP Core Ruleset might have a higher rate of false positives with larger payload sizes because analyzing more data increases the likelihood that the total score exceeds the [threshold](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#score-threshold). +Request content beyond this limit may not be fully analyzed, which can affect how managed rules behave. For example, the [OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) calculates a cumulative [threat score](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#request-threat-score) based on the scores of individual rules that match a request. Larger payloads give more content for rules to match against, which increases the score and makes it more likely to exceed the [score threshold](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#score-threshold) — resulting in a false positive. -If included in your plan, you can use [request body fields](/ruleset-engine/rules-language/fields/reference/?field-category=Body) such as `http.request.body.truncated` or `http.request.headers.truncated` in [custom rules](/waf/custom-rules/) that apply appropriate actions to requests that have not been fully analyzed by Cloudflare due to the maximum body size. +If included in your plan, you can use [request body fields](/ruleset-engine/rules-language/fields/reference/?field-category=Body) in [custom rules](/waf/custom-rules/) to apply appropriate actions to requests that have not been fully analyzed. The `http.request.body.truncated` field indicates whether the request body was truncated, while `http.request.headers.truncated` indicates whether the request contained too many headers for all of them to be included. ### Zone-level deployment -At the zone level, you can only deploy each managed ruleset once. At the [account level](/waf/account/managed-rulesets/) you can deploy each managed ruleset multiple times. +At the zone level, you can deploy each managed ruleset once. At the [account level](/waf/account/managed-rulesets/), you can deploy each managed ruleset multiple times, which allows you to apply different configurations of the same ruleset to different subsets of incoming traffic. diff --git a/src/content/docs/waf/rate-limiting-rules/index.mdx b/src/content/docs/waf/rate-limiting-rules/index.mdx index 60c4fdda33b8f1..0b7da057b48704 100644 --- a/src/content/docs/waf/rate-limiting-rules/index.mdx +++ b/src/content/docs/waf/rate-limiting-rules/index.mdx @@ -8,7 +8,7 @@ tableOfContents: false import { Render } from "~/components"; -Rate limiting rules allow you to define rate limits for requests matching an expression, and the action to perform when those rate limits are reached. +Rate limiting rules allow you to define rate limits for requests matching an expression, and the action to perform when those rate limits are reached. Use rate limiting rules to prevent abuse of your websites and APIs — for example, to protect a login endpoint from brute-force attacks or to cap how many API calls a single client can make in a given time window. In the [new security dashboard](/security/), rate limiting rules are one of the available types of [security rules](/security/rules/). Security rules perform security-related actions on incoming requests that match specified filters. @@ -32,7 +32,7 @@ Refer to [How Cloudflare determines the request rate](/waf/rate-limiting-rules/r - Rate limiting rules are evaluated in order, and some actions like _Block_ will stop the evaluation of other rules. For more details on actions and their behavior, refer to [Actions](/ruleset-engine/rules-language/actions/). -- Rate limiting rules are not designed to allow a precise number of requests to reach the origin server. In some situations, there may be a delay (up to a few seconds) between detecting a request and updating internal counters. Due to this delay, excess requests could still reach the origin server before Cloudflare enforces a mitigation action (such as blocking or challenging) in our global network. +- Rate limiting rules are not designed to allow a precise number of requests to reach your origin server. There may be a delay of up to a few seconds between detecting a request and updating rate counters. Due to this delay, excess requests could still reach the origin before Cloudflare enforces a mitigation action such as blocking or challenging. For more information on how counters work, including their per-data-center scope, refer to [Request rate calculation](/waf/rate-limiting-rules/request-rate/). - Applying rate limiting rules to verified bots might affect Search Engine Optimization (SEO). For more information, refer to [Improve SEO](/fundamentals/performance/improve-seo/). diff --git a/src/content/docs/waf/rate-limiting-rules/request-rate.mdx b/src/content/docs/waf/rate-limiting-rules/request-rate.mdx index 81df6ff9dc52eb..b5f82e5d542791 100644 --- a/src/content/docs/waf/rate-limiting-rules/request-rate.mdx +++ b/src/content/docs/waf/rate-limiting-rules/request-rate.mdx @@ -11,26 +11,28 @@ head: import { Example, GlossaryTooltip } from "~/components"; -Cloudflare keeps separate rate counters for rate limiting rules for each value combination of the rule characteristics. +Cloudflare tracks request rates by maintaining separate counters for each unique combination of values in a rule's characteristics. -Consider a rule configured with the following characteristics: +For example, consider a rule with these characteristics: - IP address - HTTP header `x-api-key` -In this case, two incoming requests with the same value for the HTTP header `X-API-Key` but with different IP addresses are counted separately, since the value combination is different. Additionally, counters are not shared across data centers. +If two requests share the same `x-api-key` header value but come from different IP addresses, Cloudflare counts them separately because their characteristic combinations differ. -The counting model of this rate limiting rule is based on the number of incoming requests. Enterprise customers with Advanced Rate Limiting can also configure rules whose counting model is based on the complexity of serving incoming requests. Refer to [Complexity-based rate limiting](#complexity-based-rate-limiting) for more information. +Counters are not shared across data centers, with the exception of data centers associated with the same geographical location. + +By default, request rate is based on the number of incoming requests. Enterprise customers with [Advanced Rate Limiting](/waf/rate-limiting-rules/#availability) can also base the rate on the cost of serving each request. Refer to [Complexity-based rate limiting](#complexity-based-rate-limiting) for more information. :::note[Important notes] -- Cloudflare currently does not support global rate limiting counters across the entire network — counters are not shared across data centers. This fact is especially relevant for customers that do not add the IP address as one of the rate limiting characteristics. The only exception is when Cloudflare has multiple data centers associated with a given geographical location. In this case, the rate limiting counters are shared between those specific data centers. +- Cloudflare does not support global rate limiting counters across the entire network. Each data center maintains its own counters. The exception is when Cloudflare has multiple data centers associated with a given geographical location. In that case, those data centers share counters. This is especially relevant for customers that do not add the IP address as one of the rate limiting characteristics. -- The Cloudflare data center ID (`cf.colo.id`) is a mandatory characteristic of every rate limiting rule to ensure that counters are not shared across data centers. This characteristic does not appear in the rule configuration in the dashboard, but you must include it when [creating rate limiting rules via API](/waf/rate-limiting-rules/create-api/). +- Every rate limiting rule includes the Cloudflare data center ID (`cf.colo.id`) as a mandatory characteristic. This ensures counters remain scoped to each data center. This characteristic does not appear in the rule configuration in the dashboard, but it is added behind the scenes. When [creating rate limiting rules via API](/waf/rate-limiting-rules/create-api/), you must include the `cf.colo.id` characteristic explicitly. - The available characteristics depend on your Cloudflare plan. Refer to [Availability](/waf/rate-limiting-rules/#availability) for more information. -- In some situations, Workers subrequests made to the same zone will be counted as separate requests, which will cause the rate limiting rule to trigger sooner than expected. Refer to [Troubleshooting](/waf/rate-limiting-rules/troubleshooting/#some-workers-subrequests-are-counted-as-separate-requests) for details. +- In some situations, Workers subrequests to the same zone count as separate requests, which causes the rate limiting rule to trigger sooner than expected. Refer to [Troubleshooting](/waf/rate-limiting-rules/troubleshooting/#some-workers-subrequests-are-counted-as-separate-requests) for details. ::: @@ -121,17 +123,17 @@ Request 4 matches the rule expression and therefore Cloudflare evaluates the rat Only available to Enterprise customers with Advanced Rate Limiting. ::: -A complexity-based rate limiting rule performs rate limiting based on the complexity or cost of handling requests during a given period, instead of the number of requests in the same period. +Not all requests cost the same to serve. A simple API read might use minimal resources, while a complex database query or file export might require significantly more. Request-count-based rate limiting treats these equally — 100 lightweight requests and 100 expensive requests increment the same counter. -A common use case is to score each request with an estimate of the cost (or complexity) required to serve that request. The rate limiting rule can then enforce a maximum limit on the total complexity that each client can put on the application over a given period, regardless of the total number of requests sent by that client. +Complexity-based rate limiting addresses this by tracking a cost score that your origin server assigns to each request, and enforcing a maximum total score per client over a given period. This way, a client that sends a few expensive requests can be rate limited before reaching a high request count, regardless of the total number of requests sent. -When you configure a complexity-based rate limiting rule, the origin server must include an HTTP header in the response with its complexity score. This score corresponds to the complexity (or cost) of serving the current request. The score value must be between 1 and 1,000,000. +To use complexity-based rate limiting, your origin server must return an HTTP response header containing a numeric score for each request. This score represents the complexity or cost of serving that request. The value must be between 1 and 1,000,000. You configure which header name the rule reads from. Complexity-based rate limiting rules must contain the following properties: -- [Score per period](/waf/rate-limiting-rules/parameters/#when-rate-exceeds--score-per-period): Maximum score per period. When this value is exceeded, the rule action will execute. -- [Period](/waf/rate-limiting-rules/parameters/#when-rate-exceeds--period): The period of time to consider when evaluating the request rate. -- [Response header name](/waf/rate-limiting-rules/parameters/#when-rate-exceeds--response-header-name): Name of HTTP header in the response, set by the origin server, with the score for the current request. +- [Score per period](/waf/rate-limiting-rules/parameters/#when-rate-exceeds--score-per-period): Maximum total score allowed per period. When the total exceeds this value, the rule action executes. +- [Period](/waf/rate-limiting-rules/parameters/#when-rate-exceeds--period): The time window for evaluating the total score. +- [Response header name](/waf/rate-limiting-rules/parameters/#when-rate-exceeds--response-header-name): The HTTP response header, set by your origin server, containing the score for each request. Cloudflare keeps counters with the total score of all requests with the same values for the rule characteristics that match the rule expression. The score increases by the value provided by the origin in the response when there is a match for the counting expression (by default, it is the same as the rule expression). When the total score is larger than the configured maximum score per period, the rule action is applied. diff --git a/src/content/docs/waf/tools/lists/index.mdx b/src/content/docs/waf/tools/lists/index.mdx index 257d32620b8f6b..615c68179740c7 100644 --- a/src/content/docs/waf/tools/lists/index.mdx +++ b/src/content/docs/waf/tools/lists/index.mdx @@ -5,9 +5,11 @@ sidebar: order: 1 --- -import { FeatureTable, Render } from "~/components"; +import { FeatureTable, Render, GlossaryTooltip } from "~/components"; -Use lists to refer to a group of items (such as IP addresses) collectively, by name, in rule expressions of Cloudflare products. You can create your own custom lists or use lists managed by Cloudflare, such as [Managed IP Lists](/waf/tools/lists/managed-lists/#managed-ip-lists). +Lists allow you to group items such as IP addresses, hostnames, or autonomous system numbers (ASNs), and reference them by name in Cloudflare [rule expressions](/ruleset-engine/rules-language/expressions/). Instead of adding each item individually to every rule that needs it, you define the group once and reuse it across rules and zones. + +You can create your own [custom lists](/waf/tools/lists/custom-lists/) or use [Managed Lists](/waf/tools/lists/managed-lists/) maintained by Cloudflare, such as Managed IP Lists that provide threat intelligence data. Lists have the following advantages: @@ -26,12 +28,12 @@ Refer to each page for details. - Bulk Redirects use [Bulk Redirect Lists](/rules/url-forwarding/bulk-redirects/concepts/#bulk-redirect-lists), a different type of list covered in the Rules documentation. -- The lists described in this page are not the same as [Zero Trust lists](/cloudflare-one/reusable-components/lists/). The two types of lists support different data types and have different validation rules (for example, regarding the list name). - -- You can also use [inline lists](/ruleset-engine/rules-language/values/#inline-lists) in rule expressions. Inline lists allow you to directly include a list of values in an expression. With an inline list you do not need to configure the list items beforehand, but the items will be hardcoded in the expression. +- The lists on this page are not the same as [Zero Trust lists](/cloudflare-one/reusable-components/lists/), which support different data types and have different validation rules (for example, regarding the list name). ::: +You can also use [inline lists](/ruleset-engine/rules-language/values/#inline-lists) in rule expressions. Inline lists allow you to include values directly in an expression without creating a separate list first. However, any changes to the values require editing the rule itself. + ## List names The name of a list must comply with the following requirements: @@ -62,9 +64,9 @@ Currently, not all Cloudflare products support lists in their expressions. Refer You can search for list items in the dashboard or [via API](/api/resources/rules/subresources/lists/subresources/items/methods/list/). -For IP Lists, Cloudflare will return IP addresses/ranges that start with your search query (search by prefix). Currently, you cannot search for an IP address contained in a CIDR range of an IP List. +For IP lists, Cloudflare returns IP addresses or ranges that start with your search query. For example, searching `192.0.2` matches `192.0.2.1` and `192.0.2.0/24`, but searching for `192.0.2.100` does not match a CIDR range like `192.0.2.0/24` that contains that address. -For Bulk Redirect Lists, Cloudflare will return the URL redirects in the list where the source URL or target URL contain your search query (search by substring). +For Bulk Redirect Lists, Cloudflare returns entries where the source URL or target URL contains your search query. ## Availability @@ -88,10 +90,10 @@ The following user roles have access to the list management functionality: ## Final remarks -You can only delete a list when there are no rules (enabled or disabled) that reference that list.
+You can only delete a list when no rules (enabled or disabled) reference it. -To replace the entire contents of a list, format the data as an array and use the [Update all list items](/api/resources/rules/subresources/lists/subresources/items/methods/update/) operation in the [Lists API](/waf/tools/lists/lists-api/endpoints/). +To replace the entire contents of a list at once, format the data as an array and use the [Update all list items](/api/resources/rules/subresources/lists/subresources/items/methods/update/) operation in the [Lists API](/waf/tools/lists/lists-api/endpoints/). -You cannot download a list in CSV format from the Cloudflare dashboard. If you need to download the contents of a list, use the [Get list items](/api/resources/rules/subresources/lists/subresources/items/methods/list/) operation to fetch the list items. +The Cloudflare dashboard does not support downloading a list as a CSV file. To export list contents, use the [Get list items](/api/resources/rules/subresources/lists/subresources/items/methods/list/) API operation. diff --git a/src/content/partials/waf/custom-rulesets/intro.mdx b/src/content/partials/waf/custom-rulesets/intro.mdx index 1357e630908ac4..108ba88d53b795 100644 --- a/src/content/partials/waf/custom-rulesets/intro.mdx +++ b/src/content/partials/waf/custom-rulesets/intro.mdx @@ -5,6 +5,20 @@ params: Custom rulesets are collections of custom rules that you can deploy at the { props.scope == "account" ? "account" : "zone" } or {props.scope == "account" ? zone level : account level }. -Like [custom rules](/waf/custom-rules/){props.scope == "account" && " at the zone level" }, custom rulesets allow you to control incoming traffic by filtering requests. For example, you can apply a custom ruleset to all incoming {props.scope == "account" ? "traffic of your Enterprise domains" : "requests of your zone" } or to a subset of incoming requests. +Like [custom rules](/waf/custom-rules/){props.scope == "account" && " at the zone level" }, custom rulesets allow you to control incoming traffic by filtering requests. + +{/* prettier-ignore-start */} + +{props.scope == "account" ? ( +

+ Account-level custom rulesets allow you to define a set of custom rules once and apply them across multiple Enterprise zones in your account. Instead of configuring each zone individually, you create a ruleset at the account level and use expressions to control which zones and traffic it applies to. +

+) : ( +

+ For example, you can apply a custom ruleset to all incoming requests of your zone or to a subset of incoming requests. +

+)} + +{/* prettier-ignore-end */} At the zone level, all customers can create and deploy custom rulesets. Custom rulesets at the account level require an Enterprise plan. For more details, refer to [Availability](/waf/custom-rules/#availability).