Why it matters

Architecture and coding practice decide whether one bug becomes a breach: dependency hygiene, defensive coding and safe concurrency limit the damage.

How to meet these requirements

  • Keep an SBOM, monitor dependencies for vulnerabilities, and update them within documented timeframes.
  • Isolate risky components, and defend against functionality that is time-consuming or resource-intensive.
  • Code defensively against mass assignment, prototype pollution and parameter pollution.
  • Synchronize access to shared resources to avoid race conditions.

Requirements

Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-15.1.1.

V15.1 Secure Coding and Architecture Documentation · 5 requirements

For the whole section: Place each security control in the pipeline and decide what it blocks (guide) · Choose and evaluate application security testing tools (guide) · Audit unsafe Rust, FFI boundaries and crate dependencies (guide) · Map PCI DSS Requirement 6 to engineering practice and evidence (guide)

  1. V15.1.1 Level 1

    Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components.

    On this site: Respond to an exploited or malicious dependency (guide) · Triage new dependency vulnerability findings (guide)

  2. V15.1.2 Level 2

    Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories.

    On this site: Respond to an exploited or malicious dependency (guide) · Generate an SBOM for the software you actually release (guide) · Review dependency health without treating a score as a guarantee (guide) · Stop dependency confusion and typosquatting at install time (guide)

  3. V15.1.3 Level 2

    Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This must include how to prevent a loss of availability due to overusing this functionality and how to avoid a situation where building a response takes longer than the consumer's timeout. Potential defenses may include asynchronous processing, using queues, and limiting parallel processes per user and per application.

    On this site: Bound API work, not just request counts (guide)

  4. V15.1.4 Level 3

    Verify that application documentation highlights third-party libraries which are considered to be "risky components".

    On this site: Review dependency health without treating a score as a guarantee (guide)

  5. V15.1.5 Level 3

    Verify that application documentation highlights parts of the application where "dangerous functionality" is being used.

V15.2 Security Architecture and Dependencies · 5 requirements

For the whole section: Place each security control in the pipeline and decide what it blocks (guide) · Choose and evaluate application security testing tools (guide) · Audit unsafe Rust, FFI boundaries and crate dependencies (guide) · Case study: the Shai-Hulud npm worm (2025-2026) (guide) · Map PCI DSS Requirement 6 to engineering practice and evidence (guide)

  1. V15.2.1 Level 1

    Verify that the application only contains components which have not breached the documented update and remediation time frames.

    On this site: Respond to an exploited or malicious dependency (guide) · Triage new dependency vulnerability findings (guide)

  2. V15.2.2 Level 2

    Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based on the documented security decisions and strategies for this.

    On this site: Bound API work, not just request counts (guide) · Bound background jobs and make retries safe (guide) · Sandbox model-generated code and computer-use agents (guide) · Unbounded resource consumption (fix card)

  3. V15.2.3 Level 2

    Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functionality such as test code, sample snippets, and development functionality.

  4. V15.2.4 Level 3

    Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack.

    On this site: Investigate a suspected malicious package safely (guide) · Treat model releases as executable supply-chain inputs (guide) · Stop dependency confusion and typosquatting at install time (guide)

  5. V15.2.5 Level 3

    Verify that the application implements additional protections around parts of the application which are documented as containing "dangerous functionality" or using third-party libraries considered to be "risky components". This could include techniques such as sandboxing, encapsulation, containerization or network level isolation to delay and deter attackers who compromise one part of an application from pivoting elsewhere in the application.

    On this site: Convert untrusted office documents and PDFs in an isolated parser (guide) · Treat model releases as executable supply-chain inputs (guide) · Sandbox model-generated code and computer-use agents (guide)

V15.3 Defensive Coding · 7 requirements

For the whole section: Prevent NoSQL, LDAP, XPath and expression-language injection (guide) · Validate input safely and prevent regex denial of service (guide)

  1. V15.3.1 Level 1

    Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some individual fields should not be accessible to users.

    On this site: Authorize functions and fields as well as objects (guide)

  2. V15.3.2 Level 2

    Verify that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality.

    On this site: Constrain server-side fetches to their intended destinations (guide)

  3. V15.3.3 Level 2

    Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action.

    On this site: Authorize functions and fields as well as objects (guide) · Keep untrusted object keys out of prototype and authority paths (guide) · Mass assignment (over-posting) (fix card)

  4. V15.3.4 Level 2

    Verify that all proxying and middleware components transfer the user's original IP address correctly using trusted data fields that cannot be manipulated by the end user, and the application and web server use this correct value for logging and security decisions such as rate limiting, taking into account that even the original IP address may not be reliable due to dynamic IPs, VPNs, or corporate firewalls.

    On this site: Preserve framework security controls across the request lifecycle (guide)

  5. V15.3.5 Level 2

    Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations. This is to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type.

    On this site: NoSQL operator injection (fix card)

  6. V15.3.6 Level 2

    Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals.

    On this site: Keep untrusted object keys out of prototype and authority paths (guide)

  7. V15.3.7 Level 2

    Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields).

V15.4 Safe Concurrency · 4 requirements

For the whole section: Create temporary files safely: mkstemp, O_EXCL and private directories (guide)

  1. V15.4.1 Level 3

    Verify that shared objects in multi-threaded code (such as caches, files, or in-memory objects accessed by multiple threads) are accessed safely by using thread-safe types and synchronization mechanisms like locks or semaphores to avoid race conditions and data corruption.

  2. V15.4.2 Level 3

    Verify that checks on a resource's state, such as its existence or permissions, and the actions that depend on them are performed as a single atomic operation to prevent time-of-check to time-of-use (TOCTOU) race conditions. For example, checking if a file exists before opening it, or verifying a user’s access before granting it.

    On this site: Preserve business invariants under concurrent requests (guide) · Authorize agent tools outside the model (guide) · Bound agent spending, memory and recovery (guide) · Create temporary files safely: mkstemp, O_EXCL and private directories (guide)

  3. V15.4.3 Level 3

    Verify that locks are used consistently to avoid threads getting stuck, whether by waiting on each other or retrying endlessly, and that locking logic stays within the code responsible for managing the resource to ensure locks cannot be inadvertently or maliciously modified by external classes or code.

  4. V15.4.4 Level 3

    Verify that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools, allowing lower-priority threads to proceed within a reasonable timeframe.

Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.

Guides on this site

Main subject · Guide

Keep untrusted object keys out of prototype and authority paths

Trace an actual nested-merge mutation, replace it with a narrow schema, and make authorization independent of inherited properties.

Main subject · Guide

Preserve business invariants under concurrent requests

Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through.

Main subject · Guide

Respond to an exploited or malicious dependency

When a dependency vulnerability is being exploited, or a package version is malicious, triage gives way to incident response: find every running copy, contain it, patch and redeploy, hunt for exploitation, rotate secrets and close on deployed evidence.

Main subject · Guide

Triage new dependency vulnerability findings

Turn a weekly batch of Dependabot, OSV-Scanner or npm audit findings into a short list of distinct, shipped, reachable issues, each routed to one outcome: fix, not affected, accept or escalate.

Main subject · Guide

Review dependency health without treating a score as a guarantee

Combine security practices, maintenance, licensing and product exposure into a recorded adoption or replacement decision.

Also covers this · Guide

Authorize functions and fields as well as objects

Prevent mass assignment, sensitive-field exposure and administrative actions that a valid object lookup alone cannot protect.

Also covers this · Guide

Generate an SBOM for the software you actually release

Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release.

Also covers this · Guide

Bound API work, not just request counts

Protect availability and operating cost with limits on input, per-request work, concurrency, queues, and downstream spending.

Also covers this · Guide

Bound background jobs and make retries safe

Keep queues, workers and paid dependencies within a defined budget when clients retry, cancel or disappear.

Also covers this · Guide

Constrain server-side fetches to their intended destinations

Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.

Also covers this · Guide

Parse bounded JSON and XML into an explicit application schema

Separate parser capabilities from schema rules, reject ambiguous and coercible inputs, and implement the boundary in a complete Python project.

Practice

References

  1. V15 Secure Coding and Architecture (ASVS 5.0.0 source)
  2. OWASP Prototype Pollution Prevention Cheat Sheet
  3. OWASP Mass Assignment Prevention Cheat Sheet
  4. OWASP CycloneDX Bill of Materials Specification
  5. OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution

List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.