Web Application Firewall (WAF)

A Web Application Firewall inspects HTTP/HTTPS traffic between clients and web applications, blocking requests that match known attack patterns or violate defined security rules. Unlike a network firewall, which operates at layers 3–4 (IP/TCP), a WAF operates at layer 7 (application layer) and understands the semantics of HTTP — headers, methods, URIs, query strings, request bodies, cookies, and responses.

A WAF is a detective and preventive control, not a substitute for secure application development. It buys time, reduces noise, and catches common attacks, but it cannot compensate for fundamentally flawed application logic.

How a WAF Works

WAFs inspect traffic using one or more of three approaches:

Negative Security Model (Signature/Blacklist)

Blocks requests matching known attack signatures. The default approach for most WAFs.

• Pattern-matched against a rule set (e.g., OWASP CRS)
• Fast to deploy, good coverage of known vulnerability classes
• Limited against novel or zero-day attacks
• Requires ongoing rule updates

Positive Security Model (Allowlist)

Only permits requests that conform to a defined specification of what is legitimate. Everything else is blocked by default.

• Built from the application's own API schema (OpenAPI/Swagger) or learned traffic baseline
• Most effective protection — blocks unknown attacks by definition
• High upfront effort to define and maintain the allowlist
• Well-suited to APIs with a well-defined contract

Behavioural / Anomaly Scoring

Assigns a risk score to each request based on multiple signals. Requests exceeding a threshold are blocked or challenged.

• OWASP Core Rule Set (CRS) uses this model — each matched rule adds to a running score
• Configurable threshold balances false positives vs missed detections
• More flexible than pure signature matching

Most production WAFs combine all three models.

Deployment Modes

Reverse Proxy (Most Common)

The WAF sits in front of the application server, receiving all traffic and forwarding clean requests.

Client → [ WAF ] → Application Server

• Full visibility into requests and responses
• Can terminate TLS, inject security headers, rewrite URLs
• Adds a network hop (typically <5ms latency when tuned)
• Single point of failure if not deployed in HA

Transparent / Inline Bridge

The WAF is inserted into the network path at layer 2 (bridge mode), invisible to clients and servers.

• No IP address changes required
• Harder to configure and maintain
• Still a point of failure

Out-of-Band / Passive (Detection Only)

Traffic is mirrored to the WAF for analysis. The WAF cannot block — it can only alert.

• Zero impact on latency or availability
• Used in audit mode to tune rules before going inline
• Not a protective control

Cloud / CDN-based WAF

Traffic is routed through the WAF provider's infrastructure via DNS pointing the domain to the cloud WAF's IP range.

Client → [ Cloud WAF (e.g. Cloudflare, AWS WAF) ] → Origin Server

• No on-premises hardware
• Global PoPs reduce latency
• DDoS absorption capacity included
• Origin IP must be protected (clients must not bypass WAF by connecting directly to origin)

WAF Types

What a WAF Protects Against

WAFs are effective against the OWASP Top 10 and other common web attack classes:

What a WAF cannot protect against:
- Business logic flaws (incorrect authorisation decisions in the app)
- Authenticated attacks from legitimate-looking requests
- Zero-day vulnerabilities with no matching signatures
- Attacks over encrypted channels it cannot inspect (mTLS where WAF is not the TLS terminator)
- Client-side attacks (XSS that has already executed in the browser)

OWASP Core Rule Set (CRS)

The OWASP Core Rule Set is the most widely deployed open-source WAF rule set, used with ModSecurity, Coraza, and supported by many commercial WAFs.

Anomaly Scoring Mode

CRS operates in anomaly scoring mode by default:

• Each matched rule adds to an inbound anomaly score
• When the total exceeds the anomaly threshold (default: 5), the request is blocked
• This prevents blocking on a single low-confidence match while blocking on combinations of suspicious signals

# ModSecurity + CRS: key configuration directives
SecRuleEngine On                      # Detection + blocking (use DetectionOnly to start)
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.log

# CRS anomaly thresholds
SecAction \
  "id:900110,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.inbound_anomaly_score_threshold=5,\
   setvar:tx.outbound_anomaly_score_threshold=4"

Paranoia Levels

CRS has four paranoia levels:

Start at PL1 in detection mode, tune out false positives, then move to enforce mode before considering PL2.

Deployment Strategy

Phase 1 — Detection Mode (No Blocking)

Run the WAF in detection/audit mode. Log all rule matches without blocking traffic.

• Duration: 2–4 weeks minimum for applications with varied traffic patterns
• Collect and analyse false positives
• Identify legitimate requests that trigger rules (e.g., rich text editors, admin interfaces with complex payloads)

Phase 2 — Tune False Positives

For each false positive:

# Disable a specific rule for a specific URI
SecRule REQUEST_URI "@beginsWith /admin/editor" \
  "id:1001,phase:1,nolog,pass,ctl:ruleRemoveById=941100"

# Exclude a parameter from a rule
SecRuleUpdateTargetById 941100 "!REQUEST_COOKIES:_session"

# Whitelist a trusted IP range from all rules
SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8" \
  "id:1002,phase:1,nolog,allow,ctl:ruleEngine=Off"

Phase 3 — Enforce Mode (Blocking)

Enable blocking mode. Start with lower-confidence rules in detection and higher-confidence rules blocking. Monitor for new false positives after every application deployment.

Phase 4 — Ongoing Tuning

A WAF is not set-and-forget. Retuning is required after:
- Application changes (new endpoints, parameters, content types)
- CRS rule set updates
- New attack campaigns targeting the application

WAF Bypass Techniques (Know Your Limits)

Understanding bypass methods helps set realistic expectations for what a WAF achieves.

Implication: A WAF reduces the attack surface and stops unsophisticated automated attacks effectively, but a determined and skilled attacker can often find a bypass. The WAF must be paired with secure code, input validation, parameterised queries, and output encoding in the application itself.

Protecting the WAF Origin

For cloud WAFs, if attackers discover and directly access the origin server IP, the WAF is bypassed entirely.

Mitigations:
- Restrict origin server ingress to only the WAF provider's IP ranges at the network firewall level
- Use cloud WAF features like Cloudflare Authenticated Origin Pulls (client certificate on origin)
- Rotate origin IP if it has been exposed
- Do not include the origin IP in any public DNS records, email headers, or error pages

# Example: Allow only Cloudflare IPs to reach origin (iptables)
# Fetch current Cloudflare IP ranges from their API and apply as allowlist
curl -s https://www.cloudflare.com/ips-v4 | while read ip; do
  iptables -I INPUT -p tcp --dport 443 -s "$ip" -j ACCEPT
done
iptables -A INPUT -p tcp --dport 443 -j DROP

Security Headers via WAF

A WAF or reverse proxy can inject security response headers that the application may not set itself:

# Nginx WAF proxy — inject security headers on all responses
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; ..." always;

Rate Limiting and Bot Management

A WAF is the natural place to enforce rate limiting — it sees all traffic before it reaches the application.

# AWS WAF rate-based rule example
- Name: RateLimitLogin
  Priority: 1
  Statement:
    RateBasedStatement:
      Limit: 100          # requests per 5 minutes per IP
      AggregateKeyType: IP
      ScopeDownStatement:
        ByteMatchStatement:
          FieldToMatch:
            UriPath: {}
          SearchString: /login
          PositionalConstraint: STARTS_WITH
          TextTransformations:
            - Priority: 0
              Type: LOWERCASE
  Action:
    Block: {}

WAF in a DevSecOps Pipeline

Integrate WAF rule testing into CI/CD to prevent deployments from introducing new false positives or uncovered attack surface:

1. Automated security scanning (DAST — OWASP ZAP, Burp Suite) runs against staging behind the WAF
2. WAF rule set changes go through the same review process as application code
3. WAF alerts feed into the same SIEM/alerting pipeline as application logs
4. New API endpoints trigger a WAF rule review to ensure coverage

Hardening Checklist

References

• OWASP Web Application Firewall
• OWASP Core Rule Set
• ModSecurity Reference Manual
• OWASP ModSecurity CRS Docker Image
• AWS WAF Documentation
• Cloudflare WAF
• NIST SP 800-44 — Guidelines on Securing Public Web Servers