The OWASP Top 10 for Decision-Makers

Anyone who buys, builds or oversees web applications will meet the OWASP Top 10 sooner or later. It appears in requests for proposals, penetration test reports, vendor questionnaires and training catalogs. Because it is so widely referenced, it helps to understand what it actually is, and what it is not.

What the OWASP Top 10 is

OWASP, the Open Worldwide Application Security Project, is a nonprofit community that produces free application security guidance and tools. The OWASP Top 10 is its best-known document: a periodically updated list of the most critical categories of web application security risk, based on data contributed by organizations and on community input.

OWASP describes it as an awareness document. It is designed to focus attention on common, serious problems, not to define everything a secure application must do.

What the categories cover

The list changes between editions as categories are merged, renamed and reordered, so always check which edition a document refers to. In general terms, recent editions have covered:

• Access control failures, where users can see or do things beyond their permissions.
• Cryptographic failures, such as sensitive data sent or stored without adequate protection.
• Injection, where untrusted input is interpreted as commands or queries.
• Insecure design, meaning flaws built in from the start rather than introduced by coding errors.
• Security misconfiguration, including default settings, verbose errors and unnecessary features.
• Vulnerable and outdated components, and broader software supply chain risks.
• Authentication failures, such as weak session handling or missing protection against credential attacks.
• Integrity failures, where code or data is trusted without verification.
• Logging and monitoring failures that let attacks go unnoticed.

Using it in contracts and procurement

The Top 10 gives buyers and suppliers a shared vocabulary. Requiring that a delivered application be free of known vulnerabilities in the Top 10 categories is a reasonable baseline, but make it specific:

• Name the edition, or state that the current edition at the time of testing applies.
• Say how compliance will be shown, such as an independent test, code review results or both.
• Define how findings will be fixed and retested before acceptance.
• Reference the OWASP API Security Top 10 as well if the application exposes APIs.

Using it to scope testing

Asking testers to cover the Top 10 is a sensible minimum, but a test that only works through a checklist will miss flaws specific to how your application works, such as a payment workflow that can be skipped or an approval step that can be bypassed. Give testers accounts at different privilege levels, documentation and time to understand the business logic. Ask the report to map findings to Top 10 categories so leaders can see patterns across applications.

Using it in developer training

The Top 10 is a good organizing structure for secure coding training. It is most effective when training uses the organization's own languages and frameworks, shows real examples from past reviews and teaches the secure pattern alongside the flaw. Developers who understand why access control must be enforced on the server write fewer vulnerabilities than those who memorized a list.

What it does not cover

• It is not a complete standard. For detailed, testable requirements, OWASP's Application Security Verification Standard (ASVS) goes much deeper.
• It does not address every application type. APIs, mobile apps and AI-enabled applications have their own risk lists.
• It does not cover infrastructure and operations, such as cloud configuration, identity management or incident response.
• It does not replace a secure development process with threat modeling, code review, dependency management and testing built into every release.

An application can avoid every Top 10 category and still be insecure, and a report claiming Top 10 compliance says little without knowing how the testing was done. When a vendor describes a product as covering the OWASP Top 10, ask what was tested, by whom, how and when.

How CDT can help

CDT helps organizations build security into the applications they buy and develop. Our code review and penetration testing teams go beyond checklists to examine how your applications can actually be abused, and our training helps developers write secure code from the start.