OWASP Top 10

The number of holes you could close in a web application is effectively unbounded, and a team's time is not. Several hundred distinct weakness types have been catalogued. A 45-person company with nobody assigned to security full time cannot walk that catalogue in no particular order and have anything to show for it afterwards.

So reviews used to depend on who was in the room. A team with a database specialist would carefully block SQL injection — where a value typed into a form gets interpreted as part of the query that fetches data — and leave permission checks after login entirely unwritten. Another team would have it the other way around. Whatever got skipped usually surfaced as an incident rather than in a review.

The same gap showed up in conversations with customers. When an enterprise buyer asked how security was handled, the answering side listed what it happened to have done, and the asking side had no way to see what was missing. Both sides used different words for the same control.

This list exists to supply an order and a shared vocabulary. It doesn't ask you to close everything. It says which ten categories break most often, so you start there, and it gives both sides of a security conversation the same names for the same things.

Each edition holds ten entries, and an entry is a category of related weaknesses rather than the name of a single bug. Every entry carries a name and a rank, the list of specific weaknesses grouped under it, a short scenario showing how it gets exploited, and the prevention steps that close it. Ranks come from data rather than impression: they count how often each weakness turned up across hundreds of thousands of tested applications, with a practitioner survey added for the types automated scanners can't detect.

The categories themselves cover very different parts of an application.

1. Broken access control. Top of the most recent edition. Login succeeded, but nobody checked whether that person is allowed to do this particular thing — authorization is missing. Changing a document number in the address bar and getting someone else's document belongs here.
2. Cryptographic failures. Values that needed to be unreadable weren't made unreadable. Passwords stored as typed is the standard example.
3. Injection. Input gets interpreted as part of a command. Recent editions also fold in cross-site scripting (XSS), where a script somebody planted runs in another user's browser.
4. Security misconfiguration. The opening comes from settings rather than code — an admin console still on its default password, or an error page printing internal structure.
5. Vulnerable and outdated components. A third-party library you pulled in still carries a published vulnerability. Your own code is fine; the version is old.
6. Authentication failures. The authentication process itself is weak. Passwords that can be guessed indefinitely, or sessions that keep working after logout, sit here.
7. Logging and monitoring failures. You can't tell that you were attacked. An attempt that left no trace is an attempt you can't learn from, and a breach nobody noticed runs for months.

It comes from the Open Worldwide Application Security Project (OWASP), a nonprofit that works on web application security in the open. It isn't one vendor's product documentation: volunteers assemble it, and the scan data behind the rankings is contributed by a range of security firms and research groups. Editions land every few years, and entries merge or appear between them, which is why citations name the year of the edition.

Four audiences read it.

1. Developers use it as a checklist while building. Adding a screen, they confirm the permission check is there and that user input isn't being pasted into a query, using the entry names as prompts.
2. Reviewers use it as an agreed list of what to look for, so review standards don't vary by reviewer on a team with no security specialist.
3. Security reviewers at customer companies copy the entries straight into the questionnaire they send before signing. Both sides using the same names makes the answers shorter.
4. Whoever runs onboarding uses it as a teaching order — ten categories first, rather than several hundred.

Because the uses differ, expectations collide. A buyer's reviewer is looking for an answer to whether you are safe, which is not something this document can supply. Filling in a response per entry and actually having that entry closed are different states, and closing the distance between them is the job of work like a penetration test, where someone genuinely attacks the service.

"The enterprise security questionnaire has a field for each OWASP Top 10 entry."

The buyer is using this list as review criteria, so our status against each entry needs writing up.

"Broken access control has been number one for editions running, so let's start by checking every screen has a permission check."

Use the list's ranking as the order of work.

"This risk isn't on the list — it's specific to us, so I'll track it separately."

The problem falls outside what the list covers and needs its own place.

At Pagedeck the list appears as soon as an enterprise contract does. The questionnaire Sofia brings back contains all ten entries, and Theo writes the current state and remaining work for each. Last quarter the logging and monitoring entry stopped them: repeated failed logins left no record, so there was nothing to write in that field, and that one field delayed the contract by three weeks.

Since then the list doesn't come out only for contracts. Theo added permission checks and input handling to the review criteria for new screens, which costs one line of attention while building instead of a scramble after a questionnaire arrives.

The most common mistake is reading it as a finish line — close these ten and you're safe. The list ends at ten, so filling in the checklist feels like completion. But the entries were chosen by how frequently they are found, and risks unique to your own product were never in scope. For a document collaboration tool, expiry on share links or what happens to a departed employee's account are places only your structure produces. Judged by the list alone, all ten entries get answered while the holes specific to your product stay open.

Mistaking the document for a compliance certification is the other frequent error. Entries come numbered and buyers use them in reviews, so it reads like a specification. It is an awareness document that tells you what to look at first, and it carries no passing score. Writing that you comply with it invites the reader to treat that sentence as certification, and when an actual assessment says otherwise, the gap becomes a trust problem rather than a technical one.