OWASP Top 10, Five Years Later
Earlier in this series
The OWASP Top 10 gets revised every few years. The names shift, categories merge and split, and the ordering gets debated. And yet if you squint at any two editions, you are looking at the same list.
I have a specific relationship with this document. When I ran my own startup, I built our secure development standards on OWASP guidance — I wrote about that in Building a Vulnerability Management Program from Zero. Since going independent, I have used it with consulting clients as a shared vocabulary. Years of watching small teams meet the same list has left me with a firm opinion: the persistence of the Top 10 is not a failure of awareness. It is telling us something about where these bugs actually come from.
The categories that never leave
Strip away the renaming across editions and a hard core remains.
Broken access control. Year after year, edition after edition, this sits at or near the top, and it matches what I see in practice. Not exotic bypasses — missing checks. An API endpoint that verifies you are logged in but not that the record you requested is yours. An admin function protected only by not being linked in the UI. When I directed a penetration test of our own mobile app before launch, findings clustered in exactly this territory, and the pattern has repeated in client engagements since.
Injection. Frameworks have made classic SQL injection genuinely harder to write. But injection is a family, not a bug: command injection, template injection, injection into that one raw query somebody wrote "just for this report." The category shrinks. It does not close.
Security misconfiguration. Default credentials, debug modes in production, cloud storage open to the world, permissive CORS. This category grows as stacks grow, because every added component ships with settings, and settings ship optimized for "works immediately," not "safe."
Vulnerable and outdated components. Your code is a thin layer on a mountain of dependencies, and the mountain ages. Every team knows this. Very few teams have a working answer for it, which is why the category never leaves.
Authentication and session failures. Password handling, session expiry, reset flows, missing MFA on the accounts that matter. Login is the front door, and teams still build their own locks.
Why they persist
Here is the uncomfortable part. None of these categories persist because the knowledge is missing. Everything above has been documented, with fixes, for as long as the list has existed. They persist for structural reasons, and I saw all three of these reasons from the inside as a founder.
Access control is business logic, so no tool catches it. A scanner can find an outdated library. No scanner knows that user A must never see invoice B. Authorization bugs are correctness bugs in your specific domain, invisible to generic tooling, and they multiply every time you add an endpoint. The only defenses are architectural — one central place where authorization decisions happen — and human review that asks "who can call this?" on every new route.
Misconfiguration is what "moving fast" looks like from the outside. Nobody decides to expose a storage bucket. Someone opens it to debug a launch-week problem, the launch succeeds, and the setting outlives the memory of it. Configuration drifts toward permissive because permissive is what unblocks people. Without a periodic pull in the other direction — a review, a baseline, anything — drift wins.
Outdated components are a scheduling problem wearing a technical costume. Updating a dependency has an immediate cost — testing, possible breakage — and a deferred, invisible benefit. Under deadline pressure, that trade loses every single sprint. It only gets fixed when updating becomes cheap and automatic: lockfiles, a scanner in the build, small frequent bumps instead of terrifying annual migrations. At my startup, wiring dependency checks into the pipeline did more than any policy paragraph on the subject.
In other words: the Top 10 endures because it is a list of economic and organizational failure modes, expressed as technical symptoms. Teams treat it as a knowledge problem, distribute a link, and consider awareness achieved. The bugs are not caused by not knowing. They are caused by incentives, and incentives do not read wikis.
What actually trips up startups
From consulting with small and mid-sized organizations, my honest short list of what bites early-stage teams, in rough order:
- Object-level authorization gaps — the
/api/thing/{id}endpoint that never checks ownership. - Secrets in the wrong place — credentials in the repo, in client-side code, in a config file that ends up somewhere public.
- Dependency drift — not one dramatic vulnerable library, but the accumulated absence of any update habit.
- Production configuration nobody owns — settings made during an emergency, never revisited.
- Homemade authentication — custom session logic where a framework or identity provider would have been safer and cheaper.
Notice what is missing: sophisticated attacks. Startups do not get beaten by brilliance. They get beaten by the same five doors left open.
How to actually use the list
The wrong way to use the Top 10 is as a compliance checklist — ten boxes, ticked annually. The list is explicitly awareness material, not a standard, and treating it as a standard produces exactly the theater it was meant to prevent.
The right way, in my experience, is as a curriculum and a review lens. Take one category per month. Have the team find where that class of issue could live in your codebase. Turn what you find into the small set of code-review checks I described building at my startup — and keep that set short, because a checklist grows until it is ignored.
Do that for a year and you will have covered the list in a way that changed your code, not your paperwork.
Five years from now
I expect the next editions of the list to reshuffle again. Supply chain and design-level categories will likely keep rising, as of this writing they already have. And I expect broken access control, misconfiguration, and outdated components to still be there, because the forces that produce them — business logic no tool can see, drift toward permissive, deferred maintenance — are not going anywhere.
Which is oddly hopeful. It means the defense is stable too. You do not need to chase novelty. You need a small set of durable habits applied continuously — and for teams without a security hire, that set is smaller than you think. That is the next piece.