OWASP and the Vulnerability Classes That Won’t Die

The same vulnerability classes have topped OWASP lists for two decades. Why they persist, and what actually stops them from recurring.

The list is repetitive on purpose

The Open Worldwide Application Security Project (OWASP) publishes a periodically updated list of the most critical web application security risks. Anyone glancing at successive versions notices that the entries change less than you might expect. Injection, broken access control, and cryptographic failures have all appeared for two decades. This is not a failure of the list. It is a description of the industry.

Why the same bugs keep recurring

These vulnerabilities persist for structural reasons rather than because developers forget them. New developers enter the industry every year without exposure to the specific mistakes their predecessors made. New frameworks and libraries expose new variants of the same underlying flaw. Time pressure means that security review is the first thing cut when a deadline moves.

The pattern is that the vulnerability class does not go away. The technology it appears in does.

The recurring headline issues

  • Broken access control — authorisation checks that verify identity but not entitlement, letting one user reach another user’s data
  • Injection — user input treated as code, whether SQL, command, or template
  • Cryptographic failures — weak algorithms, poor key management, or protection applied at the wrong layer
  • Insecure design — an architecture that made the vulnerability inevitable before any line was written
  • Security misconfiguration — defaults left in place, cloud services opened wider than intended

What actually reduces recurrence

Awareness training alone rarely changes the numbers meaningfully. What does move the needle is a combination of design-time controls and automation:

  • Frameworks and libraries that make the safe path the default and the unsafe path harder
  • Static analysis tuned to the codebase, retiring rules that generate more noise than signal
  • Peer review with security review as an explicit step, not an implicit one
  • Threat modelling for new features, catching insecure design before it ships
  • Retrospectives after security bugs are found, aimed at the process rather than the individual

Related in the Knowledge Base

Free Download

Know what an attacker sees before they do.

A practical exposure checklist covering the gaps that cause most breaches, plus what POPIA actually requires you to have in place.

Free PDF · No spam · Unsubscribe anytime

Send me the checklist