The OWASP Top 10 is the most widely referenced list of web application security risks, published by the Open Worldwide Application Security Project (OWASP) , a respected non-profit. It is written for security professionals, but the risks it describes have direct business consequences: data breaches, downtime, fines, and lost trust. This guide explains each category in plain English so you can ask the right questions about your own applications.

OWASP revises the list every few years as attack patterns evolve. The categories below reflect the well-established 2021 revision, which remains the standard reference for most teams; the underlying risks are stable even as their ranking shifts.

TL;DR

  • The OWASP Top 10 is the industry-standard list of the most critical web application security risks
  • The biggest categories are about access control, weak cryptography, injection flaws, and insecure design decisions made early
  • Most of these risks come down to a few root causes: missing checks, misconfiguration, outdated components, and inadequate monitoring
  • You do not need to be technical to hold your team or supplier accountable for addressing each one

1. Broken Access Control

What it means: Users can do or see things they should not, for example viewing another customer’s data by changing an ID in the URL, or reaching an admin function without being an admin.

Why it matters: This is consistently one of the most common and damaging risks. It leads directly to data exposure and unauthorised actions.

Ask your team: Are permissions enforced on the server for every request, not just hidden in the interface?

2. Cryptographic Failures

What it means: Sensitive data (passwords, payment details, personal information) is not properly protected, for example not encrypted in transit or at rest, or protected with weak or outdated algorithms.

Why it matters: Exposed sensitive data triggers breaches and, under UK GDPR, potential fines and mandatory disclosure.

Ask your team: Is all traffic over HTTPS, and is sensitive data encrypted at rest with modern algorithms?

3. Injection

What it means: Untrusted input is treated as a command, letting an attacker manipulate a database (SQL injection) or run unintended operations. Cross-site scripting (XSS) is included here.

Why it matters: Injection can expose or destroy entire databases and hijack user sessions.

Ask your team: Do we use parameterised queries and validate and encode all user input?

4. Insecure Design

What it means: The security weakness is in the design itself, not just the code, for example a password-reset flow that can be abused, or a checkout that trusts a price sent by the browser.

Why it matters: Design flaws cannot be patched away later; they require rethinking the feature. Security has to be considered up front.

Ask your team: Do we threat-model important features before building them?

5. Security Misconfiguration

What it means: Insecure default settings, unnecessary features left enabled, verbose error messages, or missing security headers.

Why it matters: Misconfiguration is extremely common and often trivial for attackers to find and exploit.

Ask your team: Are default accounts removed, unused features disabled, and security headers in place?

6. Vulnerable and Outdated Components

What it means: The application relies on third-party libraries, frameworks, or plugins with known vulnerabilities that have not been updated.

Why it matters: Attackers scan for known vulnerable components at scale. Many major breaches trace back to an unpatched dependency.

Ask your team: Do we track our dependencies and update them promptly when vulnerabilities are disclosed?

7. Identification and Authentication Failures

What it means: Weak login systems: poor password policies, no protection against brute force, weak session handling, or missing multi-factor authentication.

Why it matters: Compromised accounts are a direct route to data and functionality.

Ask your team: Do we offer multi-factor authentication and protect against credential stuffing and brute force?

8. Software and Data Integrity Failures

What it means: Trusting code, updates, or data from sources that are not verified, for example an insecure software update mechanism or a compromised build pipeline (a supply-chain risk).

Why it matters: Supply-chain attacks are growing and can compromise many victims at once through a single trusted channel.

Ask your team: Do we verify the integrity of updates and dependencies and secure our build and deployment pipeline?

9. Security Logging and Monitoring Failures

What it means: Not recording security-relevant events, or not watching them, so attacks go unnoticed for long periods.

Why it matters: You cannot respond to what you cannot see. Poor monitoring is why breaches often go undetected for months.

Ask your team: Do we log security events and alert on suspicious activity?

10. Server-Side Request Forgery (SSRF)

What it means: An attacker tricks the server into making requests to systems it should not, potentially reaching internal services that are not meant to be public.

Why it matters: SSRF can expose internal infrastructure and cloud metadata, and has featured in significant breaches.

Ask your team: Do we validate and restrict the destinations our server is allowed to call?

Key Takeaways

  • The OWASP Top 10 is the standard reference for web application security risk; most items reduce to missing checks, misconfiguration, outdated components, and weak monitoring.
  • Access control, cryptography, injection, and insecure design are the highest-impact categories.
  • You do not need to be technical to hold your team or supplier accountable for each risk; the questions above are a good start.
  • The most reliable way to know where you stand is an independent test.

Test Your Site Against the OWASP Top 10

The questions above start the conversation; a professional test gives you the answer. Application security testing combines static code analysis, dynamic runtime testing, dependency and supply-chain auditing, and authentication and cryptography review to find these risks in your actual application, with risk-rated findings and remediation guidance. For a broader look at securing a live site, see the website security audit guide for UK businesses .

Frequently Asked Questions (FAQ)

What is the OWASP Top 10? It is a regularly updated list of the ten most critical web application security risks, published by the Open Worldwide Application Security Project (OWASP). It is the industry-standard reference for prioritising application security work.

Is the OWASP Top 10 a complete security standard? No. It is an awareness and prioritisation document covering the most critical risks, not an exhaustive checklist. Use it as a starting point alongside deeper testing and secure-development practices.

How often is the OWASP Top 10 updated? OWASP revises it every few years as data and attack patterns change. The categories evolve and re-rank, but the underlying risks remain broadly stable, so the concepts stay relevant between revisions.

Which OWASP risk is the most dangerous? It varies by application, but broken access control and injection have historically been among the most common and damaging. The right priority for you depends on how your specific application is built and exposed.

How do I know if my application is affected? The only reliable way is testing: static analysis, dynamic testing, and a dependency audit against your actual codebase and running application. A professional application security test maps your risks to these categories with prioritised fixes.