WAF Detection and Fingerprinting

A Web Application Firewall (WAF) sits between clients and your web server, inspecting HTTP traffic and blocking requests that match known attack patterns. Knowing whether a WAF is present -- and which vendor is in use -- fundamentally changes how you approach security testing. For a deep dive into the fingerprinting techniques behind this detection, see our WAF detection and fingerprinting techniques article. CyberShield's WAF detection module identifies WAF presence and attempts to fingerprint the specific product, giving you critical context for interpreting scan results and planning remediation.

Why WAF Detection Matters

When a WAF is present, security scan results must be interpreted differently. A scan that reports zero SQL injection findings against a WAF-protected target does not mean the application is free of SQL injection. It may mean the WAF blocked the test payloads before they reached the application. Understanding this distinction prevents false confidence.

WAF detection is also essential for:

• Accurate vulnerability assessment: Findings behind a WAF represent what the WAF allowed through, not the application's true attack surface.
• Testing strategy: Penetration testers need to know whether they are testing the WAF's ruleset or the application itself.
• Defense-in-depth verification: Confirming the WAF is active validates that your perimeter defense layer is operational.
• Incident response: During an investigation, knowing the WAF vendor helps you locate and parse the correct logs.

Interpreting CyberShield WAF Detection Results

CyberShield reports WAF detection findings in two categories:

WAF Detected: The scan identified a WAF product by matching response signatures. The finding includes the detected vendor name when fingerprinting succeeds. This means your application has a perimeter defense layer, but other scan findings should be evaluated with the understanding that the WAF may have filtered some test payloads.

No WAF Detected: The scan did not identify any WAF signatures. This does not guarantee no WAF exists -- some WAFs are configured to be transparent and avoid adding identifiable headers or modifying error pages. However, the absence of detection means your application is likely directly exposed and all scan findings reflect the application's actual behavior.

Common WAF Vendors and Their Signatures

Each WAF product leaves characteristic fingerprints in HTTP responses. Here are the most common:

• Cloudflare: Adds cf-ray and cf-cache-status headers. Error pages contain "Attention Required" or "Cloudflare Ray ID." The server header reads cloudflare.
• AWS WAF / CloudFront: Returns x-amz-cf-id and x-amz-cf-pop headers. Blocked requests return a 403 with "Request blocked" messaging.
• Akamai (Kona Site Defender): Sets the akamai-grn header. Blocked responses reference a "Reference ID" for support troubleshooting.
• Imperva (Incapsula): Injects x-iinfo and x-cdn headers. Sets cookies prefixed with visid_incap_ and incap_ses_.
• F5 BIG-IP ASM: Sets x-cnection or TS prefixed cookies. Blocked pages reference "The requested URL was rejected."
• ModSecurity: Open-source WAF commonly deployed with Apache or Nginx. Blocked responses often include "ModSecurity" in the server header or error body. Ruleset behavior varies widely based on configuration.
• Sucuri: Adds x-sucuri-id and x-sucuri-cache headers. The server header reads Sucuri/Cloudproxy.

What to Do When a WAF Is Detected

When CyberShield identifies a WAF, take these steps:

1. Document the WAF vendor and version in your asset inventory. This is part of your infrastructure baseline.
2. Review scan findings with WAF context. Vulnerabilities that were detected despite the WAF are higher priority -- they represent issues the WAF does not cover.
3. Test behind the WAF when possible. If you control the infrastructure, temporarily allowlist your scanner's IP address in the WAF or test against a staging environment without WAF protection. This reveals the application's true attack surface.
4. Verify WAF ruleset coverage. Ensure the WAF is configured to protect against OWASP Top 10 categories, not just running with default rules. Also verify that your HTTP security headers are set by the application itself, not just injected by the WAF — if the WAF is bypassed, those headers disappear.
5. Check for bypass routes. Verify that the origin server is not directly accessible by IP address, bypassing the WAF entirely.

What to Do When No WAF Is Detected

The absence of a WAF means your application handles all traffic directly. Consider these actions:

1. Prioritize all findings as direct risks. Without a WAF, every vulnerability CyberShield reports is directly exploitable.
2. Evaluate WAF deployment. For internet-facing applications, a WAF provides a meaningful defense layer, especially for legacy applications that cannot be patched quickly.
3. Harden the application layer. Without perimeter filtering, input validation, parameterized queries, and output encoding become your primary defenses.
4. Implement rate limiting at the application or reverse proxy level to mitigate brute force and denial-of-service attacks.

Manual Verification Techniques

To verify CyberShield's WAF detection results, use these manual checks:

Header Inspection

Send a normal request and examine the response headers for WAF signatures:

curl -sI https://yourdomain.com | grep -iE '(cf-ray|x-sucuri|x-amz-cf|x-iinfo|akamai|server)'

Trigger-Based Detection

Send a request containing a common attack pattern and observe how the server responds. A WAF will typically block the request or return a custom error page:

# Send a basic SQLi test string
curl -s -o /dev/null -w "%{http_code}" "https://yourdomain.com/?id=1' OR '1'='1"

# Send an XSS test string
curl -s -o /dev/null -w "%{http_code}" "https://yourdomain.com/?q=<script>alert(1)</script>"

A response code of 403, 406, or a redirect to a block page indicates WAF intervention. Compare this against a benign request to the same endpoint to confirm.

Cookie Analysis

Inspect cookies set by the server for WAF-specific prefixes:

curl -sI https://yourdomain.com | grep -i "set-cookie"

Look for cookies like visid_incap_, incap_ses_, __cfduid, TS01, or ak_bmsc. These are strong indicators of specific WAF products.

Origin IP Bypass Check

Verify that your origin server is not accessible directly, bypassing the WAF:

# If you know your origin IP, test direct access
curl -sI -H "Host: yourdomain.com" https://YOUR_ORIGIN_IP/

If this returns a valid response, your WAF can be bypassed entirely. Configure your origin server's firewall to accept connections only from your WAF provider's IP ranges.

Verification

After reviewing your WAF detection results and taking action, run a follow-up CyberShield scan to confirm your WAF configuration. If you deployed a new WAF, the scan should now detect it. If you blocked direct origin access, verify by scanning the origin IP separately -- it should be unreachable or return connection errors rather than your application content.