Web Application Firewall (WAF) Explained: OWASP Top 10 Guide

A Web Application Firewall (WAF) is a security control placed in front of a web application that inspects incoming HTTP/HTTPS traffic, compares it against rules or behavioral baselines, and blocks requests that look like attacks — SQL injection, cross-site scripting, path traversal, and other patterns mapped to the OWASP Top 10 — before they reach the application code. It works by evaluating every request's headers, parameters, cookies, and body against a ruleset (negative/signature-based, positive/allowlist-based, or both) and either allows, blocks, or challenges the traffic in real time. A WAF is a runtime shield, not a substitute for fixing vulnerable code or running periodic VAPT.

For Indian teams shipping customer-facing web apps — fintech portals, e-commerce checkouts, healthcare intake forms, SaaS dashboards — a WAF is one of the fastest controls to deploy that meaningfully reduces exposure to automated attack traffic, which makes up the overwhelming majority of what hits any internet-facing endpoint.

How a WAF Actually Works

A WAF sits logically between the client and the application — either as a reverse proxy, a CDN-edge module, a cloud-native service (e.g., in front of a load balancer), or an inline appliance. Every request passes through it before reaching the origin server.

The inspection pipeline typically does four things:

1. Parses the request — method, URL path, query string, headers, cookies, and body (including JSON, form-encoded, and multipart payloads).
2. Normalizes the input — decodes URL encoding, Unicode tricks, and other obfuscation attackers use to slip malicious payloads past naive filters.
3. Evaluates rules — checks the normalized request against signature patterns, anomaly scores, rate thresholds, and reputation data (known bad IPs, Tor exit nodes, data-center ASNs commonly used by scanners).
4. Takes an action — allow, block, log-only (monitor mode), challenge (CAPTCHA/JS challenge for suspected bots), or rate-limit.

Mapping WAF Rules to the OWASP Top 10

The OWASP Top 10 (2021 edition, the current published list) is the industry-reference categorization of the most critical web application security risks: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection (which now includes Cross-Site Scripting, merged into this category in the 2021 revision), A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, and A10 Server-Side Request Forgery (SSRF).

A WAF is directly effective against a subset of these — the ones that manifest as a malicious pattern in an inbound request:

1. Injection (A03) — SQL injection, command injection, and LDAP injection payloads contain recognizable syntax (' OR '1'='1, UNION SELECT, shell metacharacters). Signature and anomaly-scoring rules catch a large share of unsophisticated injection attempts at the request layer.
2. Cross-Site Scripting — payloads like <script>, onerror=, or encoded variants are matched against XSS signature libraries and blocked before they reach a vulnerable output context.
3. Security Misconfiguration (A05) — a WAF can block requests probing for exposed admin paths, default credentials pages, or common misconfiguration fingerprints, and can enforce security headers on responses.
4. SSRF (A10) — rules can restrict outbound-triggering parameters (URLs passed in request fields) from targeting internal IP ranges or cloud metadata endpoints.
5. Vulnerable/Outdated Components (A06) — virtual patching: a WAF rule can block exploitation attempts for a known CVE in a specific library/CMS while the underlying patch is scheduled, buying time without code changes.

Negative Model (Signatures/Blocklist) vs Positive Model (Allowlist)

WAFs operate on one of two core philosophies, and most production deployments blend both.

Rate Limiting and Bot Mitigation

A large share of malicious traffic hitting any public web app isn't a crafted exploit payload at all — it's automated: credential-stuffing bots, content scrapers, vulnerability scanners, and API abuse scripts. WAFs handle this class through:

1. Rate limiting — capping requests per IP/session/API key within a time window, tuned per endpoint (login and OTP endpoints need much tighter limits than a public product listing page).
2. Bot detection — fingerprinting (TCP/TLS/JA3 signatures, header ordering, JS-execution challenges) to distinguish browsers from scripted clients, and reputation feeds flagging known scanner/bot IP ranges and data-center ASNs.
3. CAPTCHA/JS challenges — inserted selectively when a request looks automated but isn't outright malicious, rather than blocking outright and risking a false positive on a real user.

(Qualitative distribution illustrating typical WAF-layer traffic categories; actual proportions vary by application, industry, and exposure — treat this as directional, not a benchmarked statistic.)

False Positives and Tuning

The single biggest reason WAFs get disabled or bypassed in production is unmanaged false positives — legitimate user traffic blocked because it superficially resembles an attack pattern (a customer support message containing the word "SELECT," a rich-text field with angle brackets, a legitimate API payload with nested JSON that trips an anomaly threshold).

A disciplined tuning workflow looks like this:

1. Deploy new rules or rulesets in monitor/log-only mode first — never blocking mode on day one.
2. Review logged "would-block" events against real production traffic for at least a few days to a week, covering a full business cycle.
3. Create targeted exceptions for legitimate patterns (specific parameters, content types, or user agents) rather than disabling entire rule categories.
4. Move to blocking mode incrementally, starting with the highest-confidence rules (known exploit signatures) before broader anomaly-scoring rules.
5. Re-tune whenever the application changes — a new form field, a new API version, or a new third-party integration can all trigger fresh false positives.

Why a WAF Complements — Not Replaces — VAPT and Secure Coding

A WAF blocks attack traffic at the network edge based on pattern-matching and heuristics. It does not fix the underlying vulnerability, and it cannot reason about business logic. Three gaps a WAF structurally cannot close on its own:

1. Logic flaws. A broken access control bug — where an authenticated user can change an ID in a URL and view someone else's data — produces a syntactically normal request. No signature or anomaly score flags it, because nothing about the request looks malicious.
2. Zero-day and novel payloads. Signature-based rules only catch what they've been written to recognize. A genuinely new exploitation technique can pass through until the ruleset is updated.
3. Compliance and assurance requirements. Regulatory and customer-security expectations in India increasingly call for documented, periodic VAPT — a WAF's traffic logs are not a substitute for a structured assessment that maps findings to the codebase and verifies remediation.

Practical Rollout Checklist for Indian Teams

Frequently Asked Questions

Sources: OWASP Top 10:2021 (owasp.org), NIST SP 800-53 (application security controls) (nist.gov), CERT-In guidelines on web application security (cert-in.org.in).

Want to see which OWASP Top 10 risks your own application is exposed to, independent of your WAF configuration? Book a free VAPT scan.