The OWASP Top 10 and the Expedited WAF
What Is the OWASP Top 10?
The OWASP Top 10 is the most widely used ranking of web application security risks, published by the Open Worldwide Application Security Project. Security teams, auditors, and compliance frameworks (including SOC 2 and PCI DSS) use it as a baseline for what a web application should defend against.
This guide walks through each of the ten categories from the current (2021) edition, explains the risk in plain terms, and shows which WAF protections and block codes apply. If a security questionnaire asks “how do you address the OWASP Top 10?”, this page is the answer for the traffic-filtering layer of your stack.
OWASP Coverage on Heroku
Heroku does not include a web application firewall. The platform’s router terminates TLS and forwards every request, malicious or not, straight to your dynos. Expedited WAF installs from the Heroku add-on marketplace and puts the protections described in this guide in front of your app without any application code changes. If you are being asked to demonstrate OWASP Top 10 coverage for a Heroku app, adding the WAF is the most direct way to meet the traffic-layer portion of that requirement.
One note on scope before the list: a WAF inspects and filters HTTP traffic before it reaches your application. Several OWASP categories are about how your application is designed and built internally, and no traffic filter can fully cover those. Each section below states whether WAF coverage is complete, partial, or not applicable, so you know what remains your application’s responsibility.
A01: Broken Access Control
The risk: Users acting outside their intended permissions: reading other users’ data, browsing admin areas, or fetching files that were never meant to be public.
What the WAF does: Blocks requests probing for unprotected paths, hidden admin panels, exposed file listings, and leftover web shells. You can also restrict sensitive paths yourself with Password Protection and Path Allowlisting.
Related block codes:
| Block Code | What It Caught |
|---|---|
| Restricted Directory | Request for a directory on the restricted list |
| Directory Listing | Attempt to browse raw file listings |
| Unauthorized Request | Request for a resource that requires authorization |
| Unauthorized Upload | Attempt to upload a file where uploads are not allowed |
| URL Request Manipulation | Tampered URL attempting to reach unintended resources |
| Backdoor Access | Request for known web shell and backdoor file paths |
| Intrusion Attempt | Attempts to gain deeper unauthorized access to the application |
Coverage note: Access control decisions inside your application (which logged-in user may see which record) are application logic. The WAF stops the probing and scanning that precedes exploitation, but it cannot enforce your permission model for you.
A02: Cryptographic Failures
The risk: Sensitive data exposed in transit or at rest because encryption is missing, weak, or misconfigured.
What the WAF does: Every site on the WAF gets managed TLS: certificates are issued and renewed for you, HTTPS is enforced for all traffic, and TLS versions and cipher suites are kept to current standards, with legacy protocols disabled at the edge.
Related block codes: None. This category is about transport configuration rather than blocked requests.
Coverage note: Encryption of data at rest (your database, your backups) is outside the traffic layer.
A03: Injection
The risk: Attacker-supplied input that gets interpreted as code or queries: SQL injection, cross-site scripting, command injection, and template injection. Injection has appeared in every edition of the Top 10.
What the WAF does: This is the core of WAF signature matching. Requests carrying injection payloads in URLs, form fields, headers, or cookies are dropped before they reach your application, including payloads that are encoded or obfuscated to slip past simpler filters.
Related block codes:
| Block Code | What It Caught |
|---|---|
| SQL Injection | SQL syntax aimed at your database queries |
| Cross Site Scripting | Script payloads aimed at your visitors’ browsers |
| PHP Injection Blocked | Attempts to manipulate PHP language features |
| Server Side Injection | Server Side Include attack attempts |
| Remote Command Execution | Attempts to run operating system commands |
| Remote File Inclusion | Attempts to make your server fetch and execute an external file |
| User Agent Injection | Attack payloads embedded in the User-Agent header |
| Malicious Cookie Payload | Attack payloads embedded in cookies |
| Obfuscated Attack Payload | Encoded or disguised versions of the above |
| Malicious JavaScript | Requests carrying known-malicious script content |
Coverage note: Strong coverage, and you should still use parameterized queries and output escaping in your application. Defense in depth exists for the payload nobody has a signature for yet.
A04: Insecure Design
The risk: Security flaws baked into how a feature works, such as a password reset flow that leaks whether an email address is registered. There is no malicious payload to spot; the application is doing exactly what it was designed to do.
What the WAF does: Design flaws cannot be patched from the traffic layer, but the WAF limits how fast and how broadly they can be exploited: rate limiting slows enumeration and abuse of legitimate endpoints, and bot detection blocks the automation that makes design-flaw exploitation profitable at scale.
Related block codes: Brute Force Bot, Denial of Service (rate-based blocks often catch abuse of designed behavior).
Coverage note: Partial by definition. Threat modeling and secure design review happen when you build features, not when traffic arrives.
A05: Security Misconfiguration
The risk: Default credentials, verbose error pages, unnecessary features left enabled, and missing security headers.
What the WAF does: Enforces protocol discipline at the edge: malformed requests, disallowed HTTP methods, and filter-evasion tricks are dropped. Managed security headers let you set headers like X-Frame-Options and X-Content-Type-Options at the edge without touching application code, which closes the most common header gaps.
Related block codes:
| Block Code | What It Caught |
|---|---|
| HTTP Protocol Anomaly | Malformed or non-standard HTTP structures |
| HTTP Method Not Allowed | Methods your site does not accept (e.g. TRACE) |
| Evasion Request | Encoding tricks designed to bypass security filters |
| Non-standard POST Request | POST bodies that violate expected structure |
Coverage note: Configuration inside your application and hosting stack (debug modes, default passwords, open storage buckets) is yours to audit.
A06: Vulnerable and Outdated Components
The risk: Known CVEs in the frameworks, libraries, and CMS plugins your application runs on. Attackers scan the entire internet for these within hours of disclosure.
What the WAF does: Virtual patching. When a vulnerability in a common component is disclosed, WAF signatures for its exploit are deployed at the edge, typically before most applications have upgraded. Requests matching known exploits are blocked even if the vulnerable component is still installed.
Related block codes:
| Block Code | What It Caught |
|---|---|
| Exploit Blocked | Request matching a known CVE exploit signature |
Coverage note: Virtual patching buys you time; it does not remove the vulnerability. Keep dependencies updated.
A07: Identification and Authentication Failures
The risk: Credential stuffing, brute force login attempts, and weak session handling.
What the WAF does: Detects and blocks automated credential attacks: bots hammering login forms are identified by behavior and signature, and during an active attack you can put the site into lockdown from the dashboard. Password Protection adds an edge-level authentication layer in front of sensitive pages, and rate limiting caps login attempt volume.
Related block codes:
| Block Code | What It Caught |
|---|---|
| Brute Force Bot | Bots known for credential attacks |
| Two Factor Failure | Failed edge-level two-factor challenges |
| Site in Lockdown | Requests during a lockdown you have enabled |
Coverage note: Session management, password storage, and MFA inside your application remain application concerns.
A08: Software and Data Integrity Failures
The risk: Trusting code or data without verifying it: compromised CDN scripts, insecure deserialization, and tampered update channels.
What the WAF does: Deserialization attack payloads arriving in requests are caught by the injection signatures above. For third-party script risk, set a Content-Security-Policy in your application to restrict which script sources browsers will execute; the WAF passes it through unchanged and manages the rest of the security header baseline at the edge.
Related block codes: Covered by the A03 injection codes when the attack arrives in a request.
Coverage note: Partial. CI/CD pipeline integrity and dependency verification happen in your build process.
A09: Security Logging and Monitoring Failures
The risk: Breaches that go unnoticed for months because nothing recorded the early probing.
What the WAF does: Blocked requests are logged with their block code, source IP, country, and target path, visible in your dashboard and queryable via the logs API. This is an attack-side audit trail your application does not have to build, and it records the reconnaissance and exploitation traffic this category worries about.
Related block codes: All of them. The block code system is itself the monitoring layer.
Coverage note: Application-level events (logins, permission changes, data exports) still belong in your application logs.
A10: Server-Side Request Forgery (SSRF)
The risk: Tricking your server into making requests to internal systems, such as cloud metadata endpoints, by feeding it a crafted URL.
What the WAF does: Inbound requests attempting to plant SSRF payloads (URLs pointing at internal addresses in parameters) are caught by injection and remote file inclusion signatures.
Related block codes: Remote File Inclusion, Malicious Request.
Coverage note: Limited by architecture. SSRF exploitation is an outbound request from your server, and an inbound traffic filter never sees it. Validate and allowlist URLs your application fetches.
Coverage at a Glance
| OWASP Category | How to Cover It |
|---|---|
| A01 Broken Access Control | WAF blocks probing and scanning; pair with authorization checks in your app |
| A02 Cryptographic Failures | WAF manages TLS end to end; pair with encryption of stored data |
| A03 Injection | WAF blocks injection payloads; pair with parameterized queries and output escaping |
| A04 Insecure Design | WAF rate-limits abuse of designed behavior; pair with threat modeling when you build |
| A05 Security Misconfiguration | WAF enforces protocol discipline and security headers; pair with app config audits |
| A06 Vulnerable Components | WAF virtually patches known exploits; pair with dependency updates |
| A07 Authentication Failures | WAF blocks credential-stuffing bots; pair with strong session handling |
| A08 Integrity Failures | WAF blocks attack payloads; pair with an app-set CSP and build pipeline verification |
| A09 Logging and Monitoring | WAF logs every blocked request; pair with app-level event logging |
| A10 SSRF | WAF catches inbound SSRF payloads; pair with outbound URL allowlists |
If you are filling out a security review and need more detail on any category, contact support and we can provide specifics for your configuration.