By Martin Keller · Reepa Solutions
The OWASP Top 10 is the most important awareness list in web security — a collection, updated every few years, of the ten most common and impactful vulnerability classes in web applications. It is compiled by the Open Worldwide Application Security Project (OWASP), a non-profit foundation, based on empirical data from bug bounty programs, pentest reports, and security incidents. For decision-makers, development teams, and security professionals in SMEs, it is the practical starting point for the question "where are our applications most likely vulnerable?" — and it is the de-facto reference framework for "state of the art" in web application security, which GDPR audits and NIS2 assessments also follow. How this regulatory alignment works in detail is described in our Cybersecurity Guide for SMEs.
An important caveat upfront: the OWASP Top 10 is not a checklist that, once completed, makes an application "secure". It is an awareness layer with ten broad categories — each of which contains dozens of concrete vulnerability patterns. Anyone who needs a comprehensive security proof (for example for ISO 27001 or as a contractual proof for enterprise customers) should additionally use the more detailed OWASP Application Security Verification Standard (ASVS). The Top 10 says "pay attention to these ten categories"; the ASVS says "specifically verify these 250 requirements".
The Ten Categories at a Glance
The following table lists the ten categories of the OWASP Top 10:2021 with their official names and a brief description. Below, we explain each category in more detail with examples from pentest practice.
| ID | Name | What it's about |
|---|---|---|
| A01 | Broken Access Control | Users gain access to data and functions they are not entitled to |
| A02 | Cryptographic Failures | Encryption is missing, weak, or incorrectly implemented |
| A03 | Injection | User input is interpreted as code (SQL, NoSQL, OS, LDAP) |
| A04 | Insecure Design | Security gaps already present in the architecture, not just the code |
| A05 | Security Misconfiguration | Default settings, debug modes, open admin interfaces in production |
| A06 | Vulnerable and Outdated Components | Known vulnerabilities in libraries and frameworks in use |
| A07 | Identification and Authentication Failures | Weak passwords, missing MFA, broken session management |
| A08 | Software and Data Integrity Failures | Updates and pipelines without integrity checks, insecure deserialization |
| A09 | Security Logging and Monitoring Failures | Attacks go undetected because nothing is logged or monitored |
| A10 | Server-Side Request Forgery | The server fetches attacker-controlled URLs, accessing internal systems in the process |
Broken Access Control
By far the most common category in SME applications. It covers cases where users gain access to data or functions they are not entitled to — whether that is another customer's data, features restricted to other roles, or admin areas they lack permission for.
A classic finding: in the URL /api/orders/12345, a logged-in user changes the ID to /api/orders/12346 and sees another customer's order. Or: the admin panel /admin checks whether a valid login exists, but forgets to verify whether the role is Admin — any logged-in standard user gets in.
- A centralized authorization layer instead of repeating permission logic in every controller
- Default-deny: no access without an explicit permission grant
- Object-level checks — not just "is this user allowed to see orders?" but "is this user allowed to see THIS order?"
- Tests with two test accounts of different roles — if both can see the same resource, the check is broken
Cryptographic Failures
This category was previously called "Sensitive Data Exposure". It covers all cases where sensitive data is transmitted or stored without encryption, where outdated algorithms are used, or where key management is broken.
Passwords stored in the database as plaintext or with a weak hash (MD5, SHA-1). HTTP instead of HTTPS on login pages. TLS certificates using outdated RSA-1024 or weak cipher suites. Encryption keys checked into the repository. JWT tokens accepted with the algorithm set to "none". We see this regularly in older PHP applications and in custom-built authentication solutions.
- HTTPS everywhere, HSTS with preload, no HTTP endpoints in production
- Passwords hashed with bcrypt, scrypt, or Argon2 — never roll your own, never use MD5/SHA-1
- Review current TLS configuration (Mozilla SSL Configuration Generator as a reference)
- Secrets in a dedicated secret store (Vault, AWS KMS, Azure Key Vault) — never in code
Injection
The classic. User input is interpreted as code without proper separation — whether as an SQL command, an OS command, an LDAP query, or a NoSQL filter. Modern frameworks have measurably reduced SQL injection; instead, we now find more NoSQL, GraphQL, template, and command injection.
A search function builds SQL via string concatenation: "SELECT * FROM users WHERE name = '" + input + "'". Submitting ' OR '1'='1 as input returns all users. Or: a PDF renderer builds a LaTeX file from user input, which leads to code execution in some engines. Or: a logging framework like log4j interprets ${jndi:ldap://...} as an expression (the Log4Shell class of vulnerability).
- Parameterized queries / prepared statements everywhere (this is the most effective protection)
- Use ORM layers correctly — no string concatenation in custom queries
- Allowlist validation for structured inputs (email format, date format, numeric)
- For OS calls, use parameter arrays passed to the shell instead of string concatenation
Insecure Design
New since the 2021 edition. This category differs from the others because it does not describe an implementation weakness, but an architectural flaw — the application was designed in a way that makes it fundamentally unable to fulfill a particular security requirement.
An e-commerce platform allows unlimited login attempts on a customer account. No implementation can fix this later — a rate limit or lockout concept must first be built into the architecture. Or: a password reset flow sends the new password via email — regardless of how cleanly the email is delivered, the design is flawed because the email channel is not considered a secure transport.
- Threat modeling before implementation (STRIDE or OWASP threat modeling methodology)
- Treat security requirements the same as functional requirements — with acceptance criteria
- Architecture reviews with an explicit security focus
- OWASP ASVS Level 1 as a minimum design control for any application handling personal data
Security Misconfiguration
Incorrect or default-left configurations. In our pentest practice, this is the second most common finding class after Broken Access Control. It is so prevalent because modern software stacks consist of dozens of components, each with its own configuration options, and few teams know all the secure defaults.
Debug modes in production leaking detailed stack traces. Management interfaces (phpMyAdmin, Adminer, Tomcat Manager, Grafana) exposed to the internet without protection. Default passwords in CMS and databases. CORS headers configured too permissively. Cloud storage buckets accidentally set to public. Security control headers (CSP, HSTS, X-Frame-Options) missing entirely.
- Hardening baselines per technology stack, automatically enforced in deployment pipelines
- Infrastructure as Code with security linting (tfsec, checkov, Snyk IaC)
- Continuous external attack surface monitoring — such as Reepa Security — to catch newly exposed configuration errors within days
- Regular configuration reviews not just in production, but also in staging and pre-prod environments
Where does your web application stand against the OWASP Top 10?
A focused web application pentest aligned to the OWASP Top 10 delivers a clear picture in two to three weeks — each category tested, every finding with reproduction steps and prioritization. Fixed-price options available for SME applications.
Request a web pentestVulnerable and Outdated Components
Today, applications consist of 60 to 90 percent third-party code: libraries, frameworks, container images, platform components. Each of these components can have vulnerabilities, and if versions are not updated systematically, known CVEs accumulate. Log4Shell (December 2021) demonstrated exemplarily how far a single vulnerable library can reach.
A Spring Framework at version 5.2 with the Spring4Shell issue left unpatched. A WordPress plugin from 2019 that has received no updates since. A Node application with hundreds of transitive dependencies, a third of which are outdated. A Docker image based on an old Alpine base with known library CVEs. Vulnerability scanners find this within minutes — as soon as someone runs them.
- Maintain a Software Bill of Materials (SBOM) for every application, automatically generated at build time
- Continuous dependency scanning in CI/CD (Snyk, Dependabot, GitHub Advanced Security, OWASP Dependency-Check)
- Patch policy with categorization — critical within 7 days, high within 30, medium within 90
- For components that cannot be patched — such as legacy applications — document compensating controls such as WAF rules
Identification and Authentication Failures
Everything related to "who's there". Weak password policies, missing or poorly implemented multi-factor authentication, broken session management, predictable session IDs, tokens without expiry, flawed logout logic. A class that has historically led to many major data breaches.
Password reset tokens that never expire. JWT tokens that cannot be invalidated server-side, so a stolen token remains usable until it expires. "Remember me" cookies containing a permanent login token without additional factors. Login endpoints without rate limiting, enabling credential stuffing attacks. MFA bypass via a parallel recovery flow that applies less rigorous checks.
- MFA mandatory for privileged accounts, optional for all others
- Passkeys / WebAuthn as the most modern form, where browser and device support allows
- Server-side controllable session management (token revocation list, server-side sessions)
- Rate limiting on login, password reset, and 2FA verification — each endpoint individually
Software and Data Integrity Failures
A more technical category that bundles two related topics: insecure deserialization (classically Java/PHP/Python pickle) and integrity-free software supply chains (updates, plugins, CI/CD pipelines). Thrust into sharp focus by the SolarWinds and Codecov incidents.
A Java application deserializes a user-submitted object — if the classpath contains the right "gadget chains", this leads to remote code execution. Or: a CI/CD pipeline pulls a build artifact from a public npm mirror URL without signature verification. Whoever compromises the mirror compromises all builds. Or: WordPress loads plugin updates from a URL without TLS pinning, vulnerable to MITM attacks on hostile networks.
- No deserialization of user-controlled data, or use exclusively typed / safe formats (JSON Schema validated)
- Signature verification for software updates and CI/CD artifacts
- Aim for provenance standards such as SLSA for your own supply chain
- Actively curate plugin and module sources — not "first result from the marketplace"
Security Logging and Monitoring Failures
Without logging and monitoring, attacks either go undetected or are discovered months later. Mandiant and IBM reports on dwell time show that SMEs take an average of 200+ days to detect a compromise — and the main reason is always the same: nobody is watching, or nothing is being logged in the first place.
Login attempts are not logged, so credential stuffing waves go unnoticed. Authentication failures are logged but end up in local files on each of 80 servers rather than a central system. Logs contain too much data (PII, passwords) or too little (no user agent, no source IP). Alerts fire 500 times a day, so nobody responds anymore.
- Structured logging (JSON) with clearly defined security events
- Central aggregation in a SIEM or log platform, ideally with a longer retention period
- Few, precise alerts with a clear runbook — not a shotgun approach
- Regular tabletop exercises to test the detection chain in a dry run — before an actual incident occurs
Server-Side Request Forgery (SSRF)
New in the 2021 Top 10. In SSRF, the server is tricked into fetching a URL controlled by the attacker — and in doing so, it accesses internal systems that would not be reachable from outside. Particularly critical in cloud environments, because the metadata endpoints (AWS, Azure, GCP) deliver temporary local credentials that a successful SSRF attack can harvest.
An image upload service accepts a URL and fetches the image server-side. Instead of an image URL, the attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/ — and receives AWS credentials for the EC2 instance profile in return. Capital One 2019 is the most well-known example of this pattern, with over 100 million records compromised.
- Outbound HTTP calls from the backend only to an allowlist of permitted hosts
- Enforce IMDSv2 in AWS (token-based, not passively retrievable)
- Network segmentation: backend services must not be able to reach cloud metadata endpoints unless strictly necessary
- Harden URL parsing and validation against DNS rebinding — do not only check the first resolution, but subsequent ones too
What the Top 10 Does Not Cover
Three important gaps that anyone using the Top 10 as a guide should be aware of.
API-specific vulnerabilities. The classic Top 10 focuses on traditional web applications. For pure APIs, there is the separate OWASP API Security Top 10 (last updated 2023), which addresses additional classes such as Broken Object Property Level Authorization, Unrestricted Resource Consumption, and Improper Inventory Management. Anyone operating a REST or GraphQL API should consult both lists.
AI-specific risks. With the wave of generative AI applications, OWASP has published its own LLM Top 10, covering prompt injection, insecure output handling, training data poisoning, and similar LLM risks. Anyone using chatbots, RAG systems, or embedded AI cannot ignore the LLM list. More on this when we publish the corresponding cluster in the AI pillar.
Business logic specifics. The Top 10 describes generic classes — it says nothing about whether in an accounting application someone can approve someone else's invoices, or whether in a logistics system shipments can be redirected. Such business logic flaws can only be found by human pentesters who understand the domain. Generic scanners do not find them. More on the relationship between automated tools and manual testing in the Penetration Test Methodology cluster.
OWASP Top 10 vs OWASP ASVS — When to Use Which
The Top 10 is awareness; the ASVS is a verification standard. Anyone building a software application should select an ASVS level and define it as an acceptance criterion:
- ASVS Level 1 — Basic requirements verifiable through black-box testing. For non-critical public applications without personal data.
- ASVS Level 2 — Recommended standard for most applications handling personal data or financial transactions. Requires grey-box testing with code access.
- ASVS Level 3 — For highly critical applications (banking, healthcare, critical infrastructure). Requires extensive architecture reviews and white-box testing.
In our practice, we recommend ASVS Level 2 as the minimum standard for new developments to SME clients with web applications that process personal data. This is considerably more concrete than "we took the OWASP Top 10 into account" — and in audits and contract negotiations it represents a demonstrable, verifiable level of assurance.
What You Can Do Today
Three pragmatic steps for an SME that wants to take the OWASP Top 10 seriously:
First — automated baseline. Run OWASP ZAP or Burp Suite Community against your main application, monthly. Known configuration issues and simple input validation gaps become visible before an attacker finds them. Time required: 1–2 hours of setup, then automatable.
Second — dependency inventory. Dependabot or Renovate on every repository, GitHub Advanced Security or Snyk for deeper analysis. Outdated components with known vulnerabilities become visible weekly rather than appearing annually in a pentest.
Third — targeted pentest. Commission an external web pentest aligned to the OWASP Top 10 at least once a year. This covers the classes that scanners cannot find — business logic, complex access controls, architectural weaknesses. More on budgeting and selection in the Pentest Costs cluster.
Anyone who implements these three steps is significantly better positioned against the most common OWASP Top 10 finding classes than 90 percent of the SME applications we see in initial consultations.
Frequently Asked Questions
What is the OWASP Top 10?
The OWASP Top 10 is a list — updated every few years — of the most widespread and impactful vulnerability categories in web applications. It is compiled by the Open Worldwide Application Security Project (OWASP), a non-profit foundation, based on empirical analysis of security reports, bug bounty data, and pentest findings. It is not a comprehensive security standard, but an awareness list designed to bring the most important vulnerability classes to the attention of developers, security professionals, and decision-makers.
Is checking off the OWASP Top 10 enough to have a secure application?
No. The Top 10 is an awareness list, not a security standard. Anyone who needs a comprehensive security proof — for example for ISO 27001, NIS2, or enterprise customer requirements — should additionally consult the OWASP Application Security Verification Standard (ASVS), which contains approximately 200 to 300 verifiable requirements depending on the level. The Top 10 is the awareness layer; the ASVS is the verification layer.
How current is the OWASP Top 10?
The last full update was published in 2021 as "OWASP Top 10:2021". A follow-up version is planned for the near future and will incorporate additional categories from the areas of API security, supply chain, and AI-specific risks. Practitioners today primarily reference the 2021 list, supplemented by the separate OWASP API Top 10 (last updated 2023) and the OWASP LLM Top 10 for AI applications.
Which OWASP category is most common?
In SME web applications, we most frequently encounter A01 Broken Access Control and A05 Security Misconfiguration in pentests — both appear in over two-thirds of all engagements. Close behind is A06 Vulnerable Components, i.e. outdated libraries with known vulnerabilities. Classic SQL injection (part of A03) is less common than before because modern frameworks typically use prepared statements by default — but we increasingly find NoSQL, GraphQL, and OS command injection variants.
How do you test for OWASP Top 10 vulnerabilities?
A combination of automated scanners and manual testing is required. Scanners such as OWASP ZAP, Burp Suite Pro, or Acunetix provide broad coverage of configuration issues and simple input validation problems. Deeper vulnerabilities — particularly business logic flaws in access controls and authentication — are not found by scanners. This is where manual testing by experienced pentesters is indispensable. For details on the process, see our article on the pentest methodology.
Are the OWASP Top 10 relevant for GDPR or NIS2?
Indirectly, yes. Neither GDPR Article 32 nor NIS2 explicitly mention the OWASP Top 10. However, both require technical measures that reflect the current state of the art, and for web applications the OWASP Top 10 is effectively the accepted state-of-the-art reference framework. An application with unresolved A01 findings will not pass as adequately protected in a data protection audit.
Have your web application tested against the OWASP Top 10.
A focused web pentest covers every OWASP Top 10 category in two to three weeks — including business logic tests that no scanner finds. Fixed-price quote within 24 hours of scope clarification.
Request a web pentest
IT security and cloud architect with over ten years of experience. Leads his team in building Reepa Security, an offensive audit platform for SMEs. Writes regularly on web security, OWASP methodology, NIS2, and cloud security.
Reviewed on: 22 May 2026 · More about Martin