The RFP says "the system must comply with the OWASP Top 10", the vendor's proposal says "developed according to the OWASP Top 10", and the penetration test report says "covers the OWASP Top 10". All three sound professional, and none of them can be accepted or rejected on evidence: the OWASP Top 10 lists ten categories of risk, not a checklist of requirements you can tick off, and OWASP says so itself[1].

This article is for managers and IT staff who commission websites or apps from outside vendors, write RFPs, or sign off on security test reports. It explains what the OWASP Top 10 is, which risks the 2025 edition lists and how it differs from 2021; what to cite in requirements and contracts instead; what to ask when a report claims to "cover the OWASP Top 10"; and what Taiwan's information system protection baseline requires at each stage of development and testing.

What the OWASP Top 10 is, and what it is not

OWASP describes the Top 10 as "a standard awareness document" for developers and web application security, representing a broad consensus about the most critical security risks to web applications[2].

The 2025 edition was first published as a release candidate; in late December 2025 OWASP removed the words "Release Candidate" from the title in the project's source files[3]. The project page now lists 2025 as the most current released version and 2021 as the previous one[2]. New RFPs, contracts and test scopes should reference 2025, but existing contracts that cite 2021 will be around for a while, so keep the two apart (see the next section).

The 2025 edition is the eighth, built on test data that contributors supplied for more than 2.8 million applications[4]. Eight of the ten categories are ranked from that data and two are chosen through a community survey: OWASP's reasoning is that test data only reflects weaknesses tools can already detect at scale, so it looks backwards, and some important risks may never be reliably testable and so never appear in the data[4]. Each category groups a set of CWEs (Common Weakness Enumeration entries); the ten categories cover 248 CWEs in total[4].

Not a standard, and not a complete list

OWASP is blunt about this in the Top 10 itself: the Top 10 is an awareness document, not meant to be a complete list, only a starting place; since its inception in 2003 many organizations have used it as a de facto industry standard, but as a coding or testing standard it is "the bare minimum"[1]. The reason is that the Top 10 documents risks, not necessarily easily testable issues: A06 Insecure Design, for example, is beyond the scope of most forms of testing, and whether logging and monitoring are actually effective can only be established through interviews and by sampling real incident responses[1]. OWASP also states that tools cannot comprehensively detect, test or protect against the Top 10 risks, and it discourages any claim of full coverage of the OWASP Top 10 because such a claim is simply untrue[1]. For an application security standard, OWASP recommends ASVS (the Application Security Verification Standard) instead, because it is designed to be verifiable and tested[1].

The 2025 Top 10

The list below uses OWASP's IDs and official English names; the examples are taken from the attack scenarios on each OWASP category page:

  1. A01:2025 Broken Access Control: access control should stop users acting outside their intended permissions; failures typically lead to unauthorized disclosure, modification or destruction of data[5]. Example: changing the account parameter in a URL to someone else's account number returns that person's account data because the application never verifies it; or access checks live only in front-end JavaScript, so an attacker calls the admin page directly from the command line[5].
  2. A02:2025 Security Misconfiguration: a system, application or cloud service set up insecurely, such as missing hardening, unnecessary ports and features enabled, default accounts and passwords unchanged, or error messages that leak stack traces[6]. Example: sample applications shipped with the application server are left on the production server, one of them an admin console still using its default password, and the attacker logs in and takes over; or a cloud provider's storage sharing permissions default to open to the Internet[6].
  3. A03:2025 Software Supply Chain Failures: breakdowns or compromises in building, distributing or updating software, often caused by vulnerabilities or malicious changes in third-party code, tools or dependencies; not tracking the versions of every component (including transitive dependencies), running outdated or unsupported components, and a CI/CD pipeline weaker than the systems it deploys all fall here[7]. Example: Shai-Hulud in 2025 was the first successful self-propagating npm worm; malicious versions of popular packages harvested sensitive data from victim environments, then used stolen npm tokens to publish more malicious versions, reaching over 500 package versions before npm disrupted it[7].
  4. A04:2025 Cryptographic Failures: lack of cryptography, insufficiently strong cryptography, leaked keys and related errors[8]. Example: a password database stored with unsalted or simple hashes is retrieved through a file upload flaw and cracked with a rainbow table of precomputed hashes; even salted hashes from fast hash functions may be cracked by GPUs[8].
  5. A05:2025 Injection: untrusted user input sent to an interpreter (a browser, a database, the command line) causes the interpreter to execute part of it as commands, ranging from cross-site scripting (XSS) to SQL injection[9]. Example: an application concatenates a URL parameter into a SQL query, and an attacker who supplies ' OR '1'='1 gets back the whole accounts table[9]. Prompt injection in large language models is covered separately in OWASP's LLM Top 10[9].
  6. A06:2025 Insecure Design: "missing or ineffective control design", which is different from an implementation defect: an insecure design cannot be fixed by a perfect implementation, because the needed controls were never created[10]. Example: a cinema chain allows group bookings of up to fifteen people before requiring a deposit; an attacker who threat models that flow might book six hundred seats across all its cinemas in a few requests, causing a massive loss of income[10].
  7. A07:2025 Authentication Failures: the system can be tricked into recognizing an invalid or incorrect user as legitimate, for example by permitting credential stuffing and brute force, allowing weak or known-breached passwords, missing or ineffective MFA, or failing to invalidate sessions at logout or after inactivity[11]. Example: attackers replay breached credential lists, or adjust passwords the way people do, turning Winter2025 into Winter2026; an application without defenses against automated attacks becomes an oracle that tells them which credentials are valid[11].
  8. A08:2025 Software or Data Integrity Failures: code and infrastructure that do not prevent untrusted code or data from being treated as trusted, such as auto-updates without sufficient integrity verification, CI/CD pulling artifacts from untrusted places, and insecure deserialization[12]. Example: a company maps support.myCompany.com by DNS to an external support provider, so every cookie set on the myCompany.com domain, including authentication cookies, is now sent to the provider, and anyone with access to the provider's infrastructure can hijack users' sessions[12].
  9. A09:2025 Security Logging & Alerting Failures: auditable events such as logins, failed logins and high-value transactions are not logged, logs are not monitored, or alerting thresholds and escalation processes are missing or ineffective; without logging and monitoring attacks cannot be detected, and without alerting it is very hard to respond quickly[13]. Example: a children's health plan provider lacked logging and monitoring and learned only from an outside party that sensitive health records of more than 3.5 million children had been accessed and modified; the breach could have been in progress since 2013, more than seven years[13].
  10. A10:2025 Mishandling of Exceptional Conditions: programs that fail to prevent, detect or respond to unusual situations, leading to crashes, unexpected behavior and sometimes vulnerabilities, including improper error handling, logical errors and failing open[14]. Example: a transfer debits one account, credits another, then logs the transaction; an attacker interrupts it with a network disruption, and if the system does not roll back the whole transaction (fail closed), the account could be drained, or a race condition could send the money several times[14].

What changed from 2021

OWASP describes two new categories and one consolidation in 2025[4]:

  • A03 Software Supply Chain Failures expands A06:2021 Vulnerable and Outdated Components to cover dependencies, build systems and distribution infrastructure; it was overwhelmingly voted a top concern in the community survey, and has the fewest occurrences in the data but the highest average exploit and impact scores from CVEs[4].
  • A10 Mishandling of Exceptional Conditions is a new category[4].
  • Server-Side Request Forgery (SSRF) has been rolled into A01 Broken Access Control[4]; in 2021 it was a category of its own, A10[15].
  • Renames: A07 was Identification and Authentication Failures; A09 was Security Logging and Monitoring Failures, renamed to stress alerting, because great logging with no alerting is of minimal value in identifying incidents[4]; A08 changed slightly from Software and Data Integrity Failures to Software or Data Integrity Failures[12].
  • Ranking moves: Security Misconfiguration rose from #5 to #2; Cryptographic Failures fell from #2 to #4; Injection from #3 to #5; Insecure Design from #4 to #6[4].

The easiest mistake in practice is the ID: A03 was Injection in 2021 and is Software Supply Chain Failures in 2025[15]. In contracts, test reports and remediation tickets, always write the full ID (A03:2025), never just A03.

Outsourced development: write ASVS into the requirements, not just the Top 10

"Complies with the OWASP Top 10" cannot be accepted or rejected, because it never defines what compliance means. A requirement you can verify cites OWASP ASVS instead: the current stable release is ASVS 5.0.0, published on 30 May 2025, and one of the project's stated aims is to provide a basis for specifying application security verification requirements in contracts[16]. ASVS requires every requirement to be verifiable, with a "pass" or "fail" outcome[17].

ASVS has three levels. L1 holds the minimum requirements and is the starting point, around 20% of all requirements; L2 is the level most applications should strive for, which means implementing L1 plus L2, around 70% of the requirements; L3 is for applications that need to demonstrate the highest level of security and adds the final ~30%, mostly defense-in-depth or hard-to-implement controls[17]. ASVS does not choose the level for you; the organization decides based on its risks and its users' expectations. Its own example: an early-stage startup collecting limited sensitive data might start at L1, but a bank would struggle to justify anything less than L3 for online banking[17]. ASVS also says it suits procurement of software and of custom development services: the buyer requires the software to be developed at ASVS level X and asks the seller to prove it[17]. Because requirement identifiers may change between versions, cite them with the version, for example v5.0.0-1.2.5, the fifth requirement in the Injection Prevention section of the Encoding and Sanitization chapter of version 5.0.0[16].

What to put in the RFP and contract

  • Name the standard and level: for example "developed to OWASP ASVS 5.0.0 Level 2, with evidence of compliance", listing key requirements in the v5.0.0 format.
  • Security decision documents as deliverables: ASVS includes documentation requirements, under which decisions such as which file types may be uploaded, how permissions work and what input validation rules apply are written down and the implementation is then compared against them[17]. Make those documents a deliverable so acceptance has something to check against.
  • Tools and their results: OWASP recommends giving developers static analysis, software composition analysis (SCA), secrets and infrastructure-as-code (IaC) scanners and teaching them to use them[1]. Ask the vendor to deliver these scan results and how findings were handled for every release.
  • Third-party components: A03 risk comes from dependencies you cannot see, so require a component inventory and a committed patching timeline; for SBOMs and vendor contract terms see Supply chain attacks.
  • Contract templates: one template OWASP points to is the Secure Software Contract Annex, but it is written for US contract law, so have qualified legal counsel review it before use[1].

For developers, implementation guidance lives in the OWASP Cheat Sheet Series: ASVS says what must be achieved, "how do I implement this requirement in my technology" is answered by the Cheat Sheet Series, and "how do I test it" by the Web Security Testing Guide (WSTG)[17]. OWASP also recommends the Cheat Sheets and the Proactive Controls for designing security in from the start, which is far more cost-effective than retrofitting it[1]. Be wary of "ASVS certified" claims: OWASP does not certify any vendors, verifiers or software, and no certification or trust mark claiming ASVS compliance is officially endorsed by OWASP[17].

What "covers the OWASP Top 10" in a test report means

OWASP's own recommendation table rates the Top 10 as "bare minimum" for penetration testing and tool support, with ASVS as the full basis[1]. So "covers the OWASP Top 10" is best read as "the testers checked the testable parts of these ten categories", not "none of these ten risks are present":

  • A06 Insecure Design: beyond the scope of most forms of testing[1]; business logic flaws need threat modeling and design review.
  • A09 Logging and alerting: penetration testers can often only tell whether they triggered incident response in a test environment, which is rarely monitored the way production is[1].
  • A03 Software supply chain: the category with the fewest occurrences in the data, which OWASP attributes to challenges in testing[4]; black-box testing from outside usually cannot see the build pipeline or the dependencies.
  • Limits of tools: as ASVS puts it, "testable using automation" is not the same as running an off-the-shelf tool[17].

Questions to ask at acceptance:

  • Which edition, tested how: 2021 or 2025? Which method was used for each category (automated scanning, manual testing, source code review)? Which categories were out of scope?
  • Accounts and source code: ASVS notes that verifying L2 and L3 requirements usually needs, besides a penetration test with valid credentials, access to documentation, source code, configuration and the people who built the system, and that merely running an automated tool is not sufficient[17]. Even L1 is not necessarily testable by an external black-box tester[17].
  • What the report lists: traditional penetration test reports list only failures; an ASVS verification report should include the scope, a summary of all requirements checked, the exceptions found and guidance on fixing them, and note any non-applicable requirements[17].

For the differences between scanning and penetration testing, rules of engagement and report acceptance, see Vulnerability scanning, penetration testing and red teaming; for reading CVEs and scores on component vulnerabilities, see CVE, CVSS, EPSS and KEV. If you lack the people to interpret results and prioritize fixes, see our vulnerability assessment service.

Related lists: APIs and LLMs

  • API Security Top 10: the current edition is 2023; first is API1:2023 Broken Object Level Authorization, and it includes API-specific risks such as API9:2023 Improper Inventory Management[18]. For app back ends and systems that expose APIs, requirements and test scope should cover this list as well.
  • Top 10 for LLM Applications: the current edition is the 2025 list, published in November 2024; first is LLM01:2025 Prompt Injection[19]. If the system includes a chatbot or features built on a large language model, include it in requirements and testing.

Taiwan: what the system protection baseline requires

Article 11 of the Regulations Governing the Classification of Cyber Security Responsibility Levels requires government agencies and specific non-government agencies to classify the information systems they develop in-house or through outsourcing according to Annex 9, and to apply the controls in Annex 10, the information system protection baseline; the central competent authority for a sector may also set its own baseline for particular types of systems at specific non-government agencies, subject to approval by the competent authority[20]. The current text was amended on 7 January 2026, and the amendments took effect on promulgation[20]. These are legal obligations for government agencies and specific non-government agencies only; other companies are not bound by them. For who is covered, see Taiwan's Cyber Security Management Act.

Annex 10 sets controls for three protection levels, high (高), medium (中) and basic (普). Under "system and service acquisition", it requires the following at each stage of the system development life cycle[21]:

  • Requirements (same for all levels): confirm the system's security requirements for confidentiality, availability and integrity.
  • Design: high and medium systems must identify threats based on the system's functions and requirements, perform risk analysis and assessment, and feed the results back into the requirements; no requirement for basic.
  • Development: medium and basic systems must implement the controls their security requirements call for, take care to avoid common software vulnerabilities, and show users only a brief error message and code when errors occur; high systems must also run "source code scanning" security testing and have a notification mechanism for serious errors.
  • Testing: medium and basic systems must run "vulnerability scanning" security testing; high systems must also run "penetration testing".
  • Deployment and maintenance: basic systems must apply updates and patches for relevant threats, close unnecessary services and ports, not use default passwords, and back up source code; high and medium systems must also apply version control and change management.
  • Outsourcing (same for all levels): when development is outsourced, the security requirements for each stage at the applicable level must be written into the outsourcing contract.
  • Acquisition: basic systems must identify the third-party software, services, libraries and other components they use; high and medium systems must also separate development, test and production environments.

Annex 10 never names OWASP, but the mapping is straightforward: "avoid common software vulnerabilities" in the development stage is exactly where the Top 10 and ASVS come in; brief error messages correspond to A02 and A10; identifying third-party components to A03; no default passwords to A02 and A07; threat analysis at design to A06.

The Ministry of Digital Affairs' audits do name the OWASP Top 10. Its 2026 (ROC year 115) joint cyber security audit plan for government contractors is run by the Administration for Cyber Security, applies to agencies under the Executive Yuan, and selects vendors to audit based on how many agencies' core systems they maintain and how many agencies they serve[22]. Its "secure system development" checks include whether the development process builds security into a secure software development life cycle (SSDLC); whether development implements the necessary controls and avoids common vulnerabilities "such as the OWASP Top 10", with source code scanning for high-level systems; whether testing includes vulnerability scanning, with penetration testing for high-level systems; and whether development, test and production environments are separated[22]. Another check asks whether, when the contracted work includes custom system development, the vendor provides proof of security testing[22]. Vendors that build systems for government agencies may meet these requirements directly through contracts and audits; other companies can use them as a reference baseline for accepting outsourced work.

Action checklist

  • Replace "complies with the OWASP Top 10" in RFP templates and contracts with "developed to OWASP ASVS 5.0.0 Level X, with evidence of compliance", and cite individual requirements with the version.
  • Choose the ASVS level by system sensitivity: L2 for most Internet-facing systems, and consider L3 for systems handling payments or large volumes of personal data.
  • Require vendors to deliver security decision documents, a third-party component inventory, and static analysis and software composition analysis results for every release.
  • In test contracts, specify the Top 10 edition, the test method for each category, whether test accounts and source code are provided, and which categories are out of scope; require the report to list everything checked and everything not applicable.
  • Always cite Top 10 categories with the full ID (for example A03:2025) to avoid confusion with 2021.
  • Add the API Security Top 10 for API-centric systems and the LLM Top 10 for systems with LLM features.
  • If the Cyber Security Management Act applies to you: confirm every system you develop in-house or through outsourcing has been classified, that outsourcing contracts state the security requirements for each stage at the right level, and that high-level systems get source code scanning and penetration testing.
  • Follow vulnerability advisories on this site and make actively exploited component vulnerabilities a focus of your next test.