This article provides best practices for investigating scenarios where Cloudflare blocks a request, script, or operation in a customer environment.
Cloudflare is used as a security control to help protect customer solutions from harmful operations, unauthorized access attempts, data theft, and data corruption. Some legitimate business operations can also match behavior patterns that are commonly associated with malicious activity. For this reason, a Cloudflare block must be investigated as a security-related event before any bypass or allowlist request is considered.
Cloudflare uses heuristic-based detection and regularly updates security rules to respond to changing attack patterns. The specific rule logic is not disclosed by Cloudflare.
As a result:
Cloudflare rules can be categorized into the following types.
Static rules block or allow requests that match a particular pattern. The behavior is easier to identify.
Example: Access to a restricted endpoint, such as login.aspx, can be blocked by a static rule.
Dynamic rules evaluate multiple request attributes and assign a cumulative threat score. A request is blocked when the score exceeds a defined security threshold.
The score can be affected by factors such as:
A single request can be allowed, while a high volume of similar requests from the same source can be blocked because the cumulative score exceeds the threshold.
Cloudflare-related cases commonly involve one or more of the following scenarios
A common scenario occurs when an item containing script content in a field cannot be opened in Content Editor or another application in the base image.
The generic practice is to store scripts as part of presentations instead of content fields, not as part of content, as updating a presentation requires a deployment which usually require a particular level of permission and is executed by a smaller team of developers, therefore considered more secure. Content editing operations are performed by a broader team of editors, and some content may be user-generated; therefore, the risk of malicious script injection is higher.
This is not a recommended approach as Content Editor postbacks can submit values from multiple item fields in a single request. Script content in one field can therefore cause Cloudflare to block an operation that appears unrelated to that field.
Typical symptoms of a Cloudflare block are HTTP 403 or “Sorry, you have been blocked” while performing an authoring operation such as:
Common payload triggers include:
Cloudflare Web Application Firewall can classify the request as cross-site scripting or template injection before the request reaches the Sitecore application. In such cases, corresponding errors might not be present in Sitecore application logs.
PowerShell-related blocks require deeper analysis. An example of a common scenario is long PowerShell scripts with massive editing/deletion operations. While they can be used for bulk content operation/import, they also can be used for data spoofing or corruption. Common triggers include:
Splitting a long script can help determine whether the issue is caused by a specific command, a request pattern, or the cumulative score generated by the full operation.
Rewriting a script can change the detection result but does not provide a durable resolution because Cloudflare rules and scoring behavior can change. Where applicable, use the following deployment-based alternatives: