WAF (Web Application Firewall): rules, tuning and layer 7 protection
A WAF (Web Application Firewall) is the security control positioned between the internet and your web application, operating at layer 7 of the OSI model to inspect, filter and block malicious HTTP and HTTPS traffic before it reaches the application code. Unlike conventional network firewalls, which filter packets by IP address and port, a WAF understands the HTTP protocol - headers, parameters, cookies, request body - and can identify sophisticated attack patterns that travel inside seemingly legitimate requests.
What a WAF is and where it operates
A WAF can be deployed in three architectural positions: as a network appliance (inline hardware), as a web server module (ModSecurity for Apache/Nginx, IIS) or as an edge service in the cloud (Cloudflare WAF, AWS WAF, Akamai Kona). In every case, traffic passes through the WAF before reaching the application; requests that match attack patterns are blocked, logged or redirected for analysis.
Operating at layer 7 lets the WAF analyze the full context of an HTTP transaction. A request with the parameter id=1 OR 1=1-- in a URL may look harmless to a packet firewall, but a WAF with SQL Injection rules will identify the pattern and block it before it reaches the database. The same principle applies to vectors such as Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), Remote File Inclusion (RFI) and command injection.
Operating modes: negative model vs. positive model
Two fundamental models drive a WAF's decision logic:
Negative model (denylist/signatures): the WAF maintains a catalog of known attack patterns. Any request that matches a pattern is blocked; the rest is allowed. This is the default model of the OWASP Core Rule Set and of most managed WAFs. The advantage is ease of operation; the disadvantage is that zero-day attacks or uncataloged obfuscated variants can slip through.
Positive model (allowlist/application profile): the WAF explicitly defines the expected legitimate behavior - which endpoints exist, which methods they accept, which parameters are valid and what the format of the values is. Any deviation from this profile is blocked. It offers more robust protection against unknown attacks, but requires detailed initial mapping of the application and ongoing maintenance as the application evolves.
In practice, most mature deployments combine the two models: CRS signatures as a baseline and custom positive rules for critical endpoints such as authentication, payment and file upload.
OWASP Core Rule Set (CRS)
The OWASP CRS is the most widely adopted open-source rule set for WAFs. Natively compatible with ModSecurity and its Go reimplementation (Coraza), the CRS is maintained by the OWASP Foundation and receives continuous updates as new attack vectors are cataloged.
The CRS uses an anomaly scoring system: each rule a request triggers adds points to a counter. When the total exceeds a configurable threshold (default: 5 points for inbound requests), the request is blocked. This design prevents false positives caused by a single ambiguous signature and allows the protection sensitivity to be graduated.
The CRS also implements paranoia levels from 1 to 4. At level 1, only high-confidence rules with a low risk of false positives are active - ideal for the start of a deployment. At level 4, all rules are active, including the most sensitive ones for highly critical applications such as financial and healthcare systems. The recommendation is to start at level 1 and raise it gradually after analyzing false positives.
Protection against the OWASP Top 10
The WAF is the most direct edge control for mitigating the OWASP Top 10 risk categories that manifest over HTTP:
- A03 - Injection (SQLi, LDAP, OS Command): rules detect sequences of SQL metacharacters (
UNION SELECT,OR 1=1, comments--and/**/), system calls and directory manipulation. - A02 - Cryptographic Failures / Data Exposure: the WAF does not encrypt, but it can block responses that contain sensitive data patterns (card numbers, CPF) via response inspection.
- A07 - Cross-Site Scripting (XSS): rules identify injected HTML tags (
<script>,onerror=,javascript:) in input parameters. - A10 - Server-Side Request Forgery (SSRF): rules detect attempts to force the application to make requests to internal addresses (169.254.169.254 of the AWS IMDS, 127.0.0.1, RFC 1918 ranges).
- A01 - Broken Access Control (partial): path traversal (
../,..%2F) and attempts to access administrative endpoints are covered by CRS rules.
It is essential to note that the WAF does not cover categories such as business logic flaws, user-context-based access control (IDOR, BOLA) and broken authentication - which require penetration testing and code review.
Tuning: reducing false positives without opening gaps
A WAF's biggest operational challenge is not the initial deployment, but the continuous tuning to balance protection and availability. False positives block legitimate users and operations; overly permissive adjustments create gaps. The following table summarizes the main tuning decisions:
| Situation | Correct approach | What to avoid |
|---|---|---|
| Rich text editor sends HTML in the body | Exception by URI + specific parameter | Disabling the XSS rule globally |
| API receives JSON with binary/Base64 fields | Exception by URI + Content-Type | Disabling body inspection globally |
| Legitimate file upload triggers a path traversal rule | Exception by upload URI + specific rule_id | Lowering the paranoia level for the whole site |
| Internal vulnerability scanner triggers rules | Allowlist by the scanner's source IP | Disabling block mode during scans |
| High volume of blocks on a public endpoint | Investigate whether it is a real attack before creating an exception | Creating an exception without analyzing the logs |
The tuning process recommended by OWASP follows the sequence: detect -> analyze -> add surgical exceptions -> block -> monitor. Never skip the detection phase in production.
Rate limiting, anti-bot and DDoS mitigation at the edge
Modern edge WAFs incorporate capabilities beyond HTTP payload inspection:
Rate limiting: limits the number of requests per IP, per session or per endpoint within a time window. Essential for mitigating credential stuffing on login endpoints, account enumeration and abuse of public APIs. Effective rules are endpoint-specific - limits on /api/auth/login should be stricter than on static pages.
Bot challenges (CAPTCHA/JavaScript challenge): for suspicious traffic that should not be blocked immediately, edge WAFs such as Cloudflare offer interactive challenges that distinguish human browsers from automation. This layer is effective against scrapers, inventory bots and automated attack tools.
Layer 7 DDoS mitigation: application-layer volumetric attacks (HTTP flood, Slowloris, attacks on computationally expensive endpoints) are detected by traffic pattern analysis and blocked at the edge, before consuming origin server resources. Providers such as Cloudflare and AWS Shield Advanced offer absorption capacity of tens of Tbps.
TLS fingerprinting and client behavior: techniques such as JA3 (TLS handshake fingerprint) and analysis of HTTP/2 header order make it possible to identify attack tools even when they operate from distinct IPs, complementing payload-signature-based analysis.
Managed WAF vs. self-managed
The choice between a managed and a self-managed solution depends on the organization's operational capacity and the level of control required:
Managed WAFs (Cloudflare WAF, AWS WAF, Imperva): deployment via DNS (edge reverse proxy) or native integration with a load balancer. Rules updated by the provider with no operational intervention. Unified log and alert dashboards. Cost proportional to traffic volume or number of rules. The main disadvantage is lower customization granularity and dependence on the vendor's roadmap for new protections.
Self-managed (ModSecurity + OWASP CRS, Coraza): full control over rules, logs and exceptions. Support for on-premises deployment or environments without access to edge providers. Requires a capable team for maintenance, applying CRS patches and responding to new vectors. Coraza, the Go implementation of the CRS compatible with Caddy and Envoy, has been gaining adoption in microservices and service mesh architectures.
The approach most adopted by organizations with high security requirements is the hybrid model: a managed edge WAF for volumetric protection and global coverage, complemented by additional inspection at the application server level for critical endpoints with highly customized rules.
Tuning checklist for a safe deployment
- Map all public endpoints before enabling any rule
- Start with OWASP CRS paranoia level 1, detection mode
- Collect a 14-day baseline of real production traffic
- Create exceptions only by URI + parameter + rule_id, never globally
- Enable rate limiting on authentication and password recovery endpoints
- Raise the paranoia level gradually (1->2) only on critical endpoints
- Promote to block mode by endpoint group, with a 48h monitoring window
- Establish a monthly review cycle: update the CRS, review exceptions, validate coverage
- Document each exception with justification, date and owner
- Integrate WAF logs with the SIEM for correlation with other security events
Limitations: what a WAF does not solve
A WAF is a compensating control, not a complete application security solution. The following classes of vulnerabilities are beyond the reach of any WAF:
- Business logic flaws: an attacker who manipulates the checkout flow to apply improper discounts sends structurally valid HTTP requests, indistinguishable from legitimate traffic to the WAF.
- Broken access control (IDOR/BOLA): accessing another user's resource via a predictable ID in the URL triggers no known attack signature.
- Broken authentication and session management: JWT tokens without proper validation, unexpired sessions and credential reuse are not detectable at the HTTP payload layer.
- Vulnerabilities in third-party components: libraries with known CVEs running on the server are not protected by the WAF if the exploitation vector uses legitimate HTTP parameters.
NIST SP 800-95 and the OWASP Application Security Verification Standard (ASVS) are explicit: a WAF must be part of a defense-in-depth strategy that includes threat modeling in design, secure code review, periodic penetration testing and continuous vulnerability management.
References
- OWASP Core Rule Set - coreruleset.org
- OWASP ModSecurity Core Rule Set Documentation - owasp.org/www-project-modsecurity-core-rule-set
- NIST SP 800-95: Guide to Secure Web Services
- OWASP Application Security Verification Standard (ASVS) v4.0
- OWASP Top 10 2021 - owasp.org/Top10
- Coraza WAF - coraza.io
Frequently asked questions
What sets a WAF apart from a traditional network firewall?
A network firewall operates at layers 3 and 4 of the OSI model - it filters packets by IP address, port and protocol. A WAF operates at layer 7 (application), inspecting HTTP/HTTPS content: headers, URL parameters, request body and cookies. This makes it possible to detect and block attacks such as SQL Injection, Cross-Site Scripting and remote file inclusion, which travel inside seemingly valid HTTP requests and go unnoticed by conventional network firewalls.
What is the OWASP Core Rule Set (CRS) and why is it the industry standard?
The OWASP Core Rule Set (CRS) is a set of generic attack-detection rules maintained by the OWASP Foundation and compatible with the ModSecurity engine. It covers the main OWASP Top 10 categories - SQLi, XSS, SSRF, file inclusion, command injection - using an anomaly scoring system (paranoia levels 1 to 4). Because it is open source, publicly audited and continuously updated, it has become the de facto reference both in self-managed deployments and as the foundation of commercial managed WAFs.
What is the difference between the negative and positive security models in a WAF?
In the negative model (denylist), the WAF blocks known attack patterns - this is the default mode of the OWASP CRS. In the positive model (allowlist), only requests that match an explicitly approved profile of legitimate behavior are accepted; everything else is blocked. The positive model offers more robust protection against zero-day attacks, but requires greater effort to map and maintain the rules for the application's expected behavior.
How do you reduce false positives without compromising WAF protection?
The correct process involves four steps: start in detection mode (log-only) for at least two weeks, collecting all blocked requests; analyze the logs to identify legitimate patterns that trigger rules; create surgical exceptions by URI, parameter or URI+rule_id pair, never disabling rules globally; and promote to block mode in stages, monitoring 403/406 error rates during the first 48 hours. Periodic CRS reviews with each new version and adjusting the paranoia level per endpoint group are complementary practices.
Managed WAF (Cloudflare, AWS WAF) or self-managed (ModSecurity/Coraza)?
Managed WAFs offer automatic rule updates, native integration with the provider's edge network and simplified operation, but impose vendor lock-in and lower customization granularity. Self-managed solutions such as ModSecurity or Coraza give full control over rules, logs and tuning, but require in-house operational capacity for maintenance. For most organizations, the hybrid approach - a managed WAF at the edge with custom rules for critical endpoints - balances coverage and control.
Does a WAF replace secure code and application security testing?
No. A WAF is a compensating control at the edge layer, not a substitute for secure development. Vulnerabilities such as broken business logic, broken access control (IDOR, BOLA), broken authentication and excessive data exposure rarely produce signatures a WAF can detect. NIST SP 800-95 and OWASP ASVS are explicit: a WAF should form part of a defense-in-depth strategy that includes threat modeling, code review, penetration testing and vulnerability management.
WAF management and edge security with Decripte
Decripte manages WAF and edge security for organizations of all sizes - from the sole proprietor to the Enterprise with more than 100,000 employees. Our team operates Cloudflare WAF, AWS WAF and ModSecurity/Coraza deployments, runs the full tuning cycle (baseline -> exceptions -> block -> review) and integrates WAF alerts into the security operations center. If your application is exposed to the internet without adequate layer 7 protection, or if you need to review and fine-tune an already-deployed WAF, explore our plans or start for free with the Threat Management plan.