Web security basics: the OWASP Top 10 in plain English

When a developer or security tester says your app has “an OWASP Top 10 issue”, they are pointing to a widely used list of the most serious categories of web application security risk. OWASP, the Open Worldwide Application Security Project, is a non-profit community that publishes free security guidance. Its Top 10 is often used as a baseline in contracts, penetration test reports and security questionnaires.

This guide explains the current list, the OWASP Top 10:2025, in plain English. For each category you get what it means, a simple example and the question to ask your team. It is a guide to the risks themselves; it won’t make you a security expert, but it will help you follow the conversation and spot gaps.

How the list is put together

The 2025 introduction explains the method. Contributors donated testing data covering more than 2.8 million applications. The team ranked eight categories from that data and chose two through a community survey, because, as the authors put it, “we only pick eight of the ten categories from the data because it’s incomplete”. Each category groups related weaknesses, so one heading can cover dozens of specific flaws.

Compared with the 2021 edition, the main changes are a new category for software supply chain failures, a new category for mishandling exceptional conditions, and server-side request forgery (SSRF) being folded into broken access control. Security misconfiguration rose from fifth to second.

The ten categories, one by one

A01: Broken Access Control

Users can do or see things beyond their permissions. OWASP’s A01 page gives the classic example: changing an account number in a web address to view someone else’s account. It reports that “100% of the applications tested were found to have some form of broken access control”. Ask: are permission checks done on the server for every request, and does the app deny access by default?

A02: Security Misconfiguration

The software is fine but set up unsafely: default passwords left on, admin panels exposed, detailed error messages shown to visitors, or cloud storage left public. Ask: do we have a hardening checklist for each environment, and who reviews settings after changes?

A03: Software Supply Chain Failures

Problems in the code and tools you depend on rather than code you wrote: outdated libraries with known flaws, compromised packages, or a tampered build process. The introduction notes it was “overwhelmingly voted a top concern” in the community survey. Ask: do we track our dependencies and get alerted to known vulnerabilities?

A04: Cryptographic Failures

Sensitive data isn’t protected properly, for example passwords stored in a reversible form, data sent without encryption, or weak, outdated algorithms. Ask: is all traffic over HTTPS, and are passwords stored with a modern password-hashing method?

A05: Injection

Untrusted input is treated as a command. SQL injection, where text typed into a form is run against the database, is the best-known form. Cross-site scripting, where attackers get their script to run in other users’ browsers, sits here too. Ask: do we use parameterised queries and encode output by default?

A06: Insecure Design

The flaw is in the plan, not the code. A password reset that relies on easily guessed security questions is insecure however well it is built. Ask: do we think through how a feature could be abused before building it?

A07: Authentication Failures

Weaknesses in how users prove who they are: allowing weak or breached passwords, no protection against automated guessing, or sessions that never expire. Ask: do we offer multi-factor authentication and limit repeated login attempts?

A08: Software or Data Integrity Failures

The app trusts updates, plugins or data without checking they haven’t been altered. Loading scripts from an untrusted source or accepting unsigned updates are examples. Ask: how do we verify that code and data come from where we think?

A09: Security Logging and Alerting Failures

Attacks go unnoticed because events aren’t logged or nobody is told. The 2025 edition renamed this category to stress that alerting is needed to act on what is logged. Ask: would we know within hours if someone was trying thousands of passwords or downloading every customer record?

A10: Mishandling of Exceptional Conditions

New for 2025. It covers what happens when things go wrong: poor error handling, logic errors and systems that “fail open”, letting a request through when a check crashes instead of blocking it. Ask: when a component fails, does the app default to the safe option?

A worked example

An example (illustration only). A start-up runs a booking app for fitness studios. A customer notices that their booking confirmation link ends in /booking/48213. Changing the number to 48212 shows another customer’s name, phone number and class time.

That is A01, broken access control. The server returned any booking whose number it was given, without checking who was asking. The fix is to check on the server that the logged-in user owns the booking before returning it, and to deny access otherwise. The team also adds tests for this rule, following OWASP’s advice that developers and QA staff “should include functional access control in their unit and integration tests”.

A good follow-up review would ask the neighbouring questions. Were there alerts when one account viewed hundreds of bookings (A09)? Did any error reveal internal details (A02)? A single incident often points to several categories at once.

How to use the Top 10 in your business

1. Share it with suppliers. Ask agencies and freelancers to explain how they address each category in your product.
2. Use it to scope security testing. Ask penetration testers to report findings mapped to the categories, so trends are easy to see.
3. Pair it with practical guidance. The OWASP Cheat Sheet Series, which OWASP describes as “a concise collection of high value information on specific application security topics”, gives developers concrete instructions for each risk.
4. Cover the basics around the app. In the UK, the NCSC’s Cyber Essentials scheme, described as “the minimum standard of cyber security recommended by the Government”, covers firewalls, secure configuration, security updates, user access control and malware protection. It complements the Top 10, which focuses on the application itself.
5. Revisit after big changes. New features, integrations and dependencies all move the picture.

Common mistakes

• Treating the list as a full standard. It names the most common categories of risk; it isn’t a complete set of security requirements, so pair it with more detailed standards and testing guides.
• Checking access only in the interface. Hiding a button doesn’t stop someone calling the server directly. Checks must happen on the server.
• Ignoring dependencies because “we didn’t write that code”. You ship it, so you own the risk.
• Logging without anyone watching. Logs that nobody reviews or alerts on don’t help in an incident.
• Testing once before launch and never again.

When this matters most

The Top 10 is most relevant if you run custom software that handles logins, payments or personal data. If your site runs entirely on a hosted platform, much of the list is the provider’s job, but misconfiguration, weak passwords, risky plugins and access settings still sit with you. Either way, it gives you a shared vocabulary with the people who build and test your product.