Configure WAF for your site

This guide walks you through enabling and configuring the Quant Web Application Firewall (WAF) to protect your site from common attacks. We’ll cover setup, tuning for your specific application, and monitoring.

What the WAF protects against

The Quant WAF protects against:

• SQL injection — Database manipulation attempts
• Cross-site scripting (XSS) — Malicious script injection
• Remote file inclusion — Attempts to include external files
• Local file inclusion — Attempts to access server files
• Protocol attacks — HTTP protocol violations
• Bot attacks — Automated malicious traffic
• Rate-based attacks — DDoS and brute-force attempts

Prerequisites

• A Quant project with a proxy rule configured
• WAF enabled for your organisation (contact support if not enabled)

Step 1: Enable WAF in report mode

Start with WAF in report mode to analyse traffic without blocking legitimate requests.

1. Go to Page Rules in the dashboard
2. Edit or create a Proxy rule for your site
3. Scroll to WAF settings
4. Enable the Web Application Firewall (WAF) toggle
5. Set Mode to Report only
6. Save the rule

In report mode, the WAF logs potential threats without blocking them. This lets you identify false positives before enabling blocking.

Step 2: Monitor WAF logs

After enabling report mode, monitor your WAF logs for a few days to understand your traffic patterns.

1. Go to Security & WAF → WAF logs
2. Review flagged requests
3. Look for patterns:
   • Are legitimate requests being flagged?
   • What rule IDs are triggering?
   • Are there obvious attack patterns?

Step 3: Tune your WAF rules

Skip rules for false positives

If legitimate requests trigger specific rules, add them to the skip list:

1. Edit your proxy rule
2. In the WAF settings, find Allow rule IDs
3. Add the rule ID(s) that trigger false positives

Common rules to review for CMS sites:

Rule Range	Type	Notes
920xxx	Protocol enforcement	May flag complex query strings
930xxx	Local file inclusion	May flag file upload paths
941xxx	XSS protection	May flag rich text editors
942xxx	SQL injection	May flag search queries

See the CRS rule documentation for details on specific rules.

Allowlist trusted IPs

Add your office, CI/CD servers, or admin IPs to the allowlist:

1. In the WAF settings, find Allow IPs
2. Add IP addresses or CIDR ranges
3. These IPs bypass WAF entirely

203.0.113.0/24
192.0.2.50

Block known bad actors

Enable the built-in Block lists:

1. Check Known bad bots — Known malicious bots
2. Check Known bad referers — Spam referer patterns
3. Check Known bad IPs — Known malicious IP ranges
4. Optionally check AI crawlers to block AI scrapers/crawlers

Step 4: Switch to block mode

Once you’ve tuned the rules and verified legitimate traffic isn’t affected:

1. Edit your proxy rule
2. Change Mode from Report only to Block
3. Save the rule

The WAF now actively blocks malicious requests.

Step 5: Configure rate limiting

Protect against DDoS and brute-force attacks with rate limiting.

IP-based rate limiting

Limits requests per IP address:

1. In the WAF settings, find IP-based rate limiting
2. Set Mode to Block (a Bot Challenge mode is also available)
3. Configure:
   • Requests/second: Threshold to trigger (e.g., 50)
   • Cooldown: Block duration in seconds (e.g., 60)

Tip

Account for all requests including assets. If a typical page load includes 30 assets, set your threshold accordingly (e.g., 50+ RPS rather than 10).

Header-based rate limiting

Limit requests based on a custom header (useful for API rate limiting):

1. Find Header-based rate limiting
2. Set Mode to Block
3. Configure:
   • Header name: e.g., X-API-Key
   • Requests/second: Threshold to trigger
   • Cooldown: Block duration

A third type, WAF hit rate limiting, can auto-ban IPs that repeatedly trigger WAF rules.

Common configurations

WordPress sites

WordPress sites often need these rule adjustments:

Skip rules:

941100  # XSS filter for admin WYSIWYG
942100  # SQL detection in search

Recommended settings:

• Paranoia level: 1 (Low)
• Enable all block dictionaries
• IP rate limit: 100 RPS (high due to asset requests)

Drupal sites

Skip rules:

941100  # XSS filter for CKEditor
941160  # XSS filter for AJAX
942100  # SQL detection in search

Recommended settings:

• Paranoia level: 1 (Low)
• Enable all block dictionaries
• IP rate limit: 100 RPS

API endpoints

For JSON APIs with sensitive operations:

Recommended settings:

• Paranoia level: 2 (Medium)
• Header-based rate limiting on API keys
• Lower IP rate limits (10-20 RPS)
• Consider POST-only WAF via separate proxy rules

Static sites

Static sites have minimal WAF requirements but still benefit from:

• Block dictionaries enabled
• Low rate limits (10-20 RPS sufficient)
• Paranoia level: 1 (Low)

Set up notifications

Get alerted when attacks occur:

1. In the WAF settings, find the notification options
2. Add your WAF Slack webhook URL (email notifications are also supported)
3. Set Min RPM to notify (e.g., 10 — only notify once hits exceed 10 per minute)

You’ll receive notifications when:

• Requests are blocked
• Rate limits are triggered
• Block dictionary matches occur

Monitor and adjust

After enabling block mode, continue monitoring:

Regular checks

• Review WAF logs weekly for new attack patterns
• Check for false positives affecting legitimate users
• Adjust rules as your application changes

Response to attacks

When you see attack patterns:

1. Identify the source — Check IP addresses and patterns
2. Add to blocklist if attacks persist from specific IPs
3. Adjust rate limits if under sustained load
4. Review notifications for attack severity

Paranoia levels explained

The Paranoia level setting maps to the OWASP Core Rule Set paranoia levels:

Level	Description	Use case
1 — Low (recommended)	Standard protection	Most websites
2 — Medium	Stricter rules	APIs, sensitive applications
3 — High	Aggressive filtering	High-security requirements
4 — Extreme	Maximum strictness	Rarely needed; expect false positives

Higher levels may require more rule tuning to avoid false positives.

Troubleshooting

Legitimate requests being blocked

1. Check WAF logs for the blocked request
2. Note the rule ID(s) triggered
3. Add to Allow rule IDs if appropriate
4. Or allowlist the IP if it’s a known-good source

Rate limit too aggressive

1. Increase the Requests/second threshold
2. Consider page asset count in your calculations
3. For authenticated users, consider header-based limiting instead

API calls failing

1. Check if your API client sends unusual headers
2. Verify request bodies aren’t triggering SQL/XSS rules
3. Consider a separate proxy rule with custom WAF settings for API paths

Next steps

• WAF reference documentation — Detailed settings reference
• CRS rules — Core Rule Set documentation
• Custom rules — Create custom WAF rules
• Security headers — Additional security hardening