← Cloudflare Fundamentals / fundamentals / reference

Scans and penetration testing policy

Customers may conduct scans and penetration tests (with certain restrictions) on application and network-layer aspects of their own assets, such as their zones within their Cloudflare accounts, provided they adhere to Cloudflare's policy.

All scans or testing must be limited to the following:

• Customer-owned IPs
• Cloudflare's designated public IPs
• The customer's registered DNS entries

Targets like *.cloudflare.com or other Cloudflare-owned destinations are only allowed as part of Cloudflare's Public Bug Bounty program. Refer to the Additional resources section for more information.

• Throttling: Scans should be throttled to a reasonable rate to prevent disruptions and ensure stable system performance.
• Scope and intent: Scans should identify the presence of vulnerabilities without attempting to actively exploit any detected weaknesses.
• Exclusions: It is recommended to exclude /cdn-cgi/ endpoints from scans to avoid false positives or irrelevant results.
• Compliance checks: Customers may conduct PCI compliance scans or verify that known vulnerabilities have been addressed.

Before starting a penetration test on your zones, set the following application security configurations for each zone you will run the test on:

1. Deploy the Cloudflare Managed Ruleset and enable all rules in the ruleset by setting Ruleset status to Enabled.

2. Deploy the Cloudflare OWASP Core Ruleset and set the following ruleset configuration:

   • Paranoia Level: PL4
   • Score threshold: High - 25 and higher

3. Create a custom rule based on the WAF attack score to block requests considered as an attack (WAF attack score between 1 and 20). Refer to the WAF attack score documentation for an example.

4. Create a custom rule based on malicious uploads detection to block requests containing content objects considered malicious. Refer to Example rules for examples of custom rules used to mitigate this kind of threat.

5. On Pro and Business plans without Bot Management, enable Super Bot Fight Mode.
   Customers with access to Bot Management should make sure that Bot Management is enabled (it is enabled by default on entitled zones).

6. Create rate limiting rules to protect key endpoints of the zone being tested. Refer to Rate limiting rule examples and Rate limiting best practices for example configurations.

Be aware that other Cloudflare security and performance features, configurations, and rules active on your account or zone can influence test results.

After completing the test, it is recommended that you review your security posture and make any necessary adjustments based on the findings.

• Cloudflare's anycast network will report ports other than 80 and 443 as open due to its shared infrastructure and the nature of Cloudflare's proxy. The reporting is expected behavior and does not indicate a vulnerability.

• Tools like Netcat may list non-standard HTTP ports as open; however, these ports are open solely for Cloudflare's routing purposes and do not necessarily indicate that a connection can be established with the customer's origin over those ports.

• Known false positives: Any findings related to the ROBOT vulnerability are false positives when the customer's assets are behind Cloudflare.

For guidelines on required notification and necessary information, refer to Simulating test DDoS attacks. Customers should also familiarize themselves with Cloudflare's DDoS protection best practices.

• Customers can download the latest Penetration Test Report of Cloudflare via the dashboard.
• For information about Cloudflare's Public Bug Bounty program, visit HackerOne ↗.