asvs/v15-secure-coding-architecture

25 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V15.1.1 Third-party component remediation timeframes

Requirement 15.1.1 (Level 1) requires verification that application documentation defines risk-based remediation timeframes for third-party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components.

V15.1.2 SBOM inventory catalog requirement

Requirement 15.1.2 (Level 2) requires verification that an inventory catalog such as a 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.

V15.1.3 Time-consuming and resource-demanding functionality documentation

Requirement 15.1.3 (Level 2) requires verification that application documentation identifies functionality which is time-consuming or resource-demanding, including how to prevent loss of availability due to overusing this functionality and how to avoid situations where building a response takes longer than the consumer's timeout. Potential defenses include asynchronous processing, using queues, and limiting parallel processes per user and per application.

V15.1.4 Risky components documentation

Requirement 15.1.4 (Level 3) requires verification that application documentation highlights third-party libraries which are considered to be risky components.

V15.1.5 Dangerous functionality documentation

Requirement 15.1.5 (Level 3) requires verification that application documentation highlights parts of the application where dangerous functionality is being used.

V15.2.1 Components within documented update timeframes

Requirement 15.2.1 (Level 1) requires verification that the application only contains components which have not breached the documented update and remediation timeframes.

V15.2.2 Defenses against availability loss from resource-demanding functionality

Requirement 15.2.2 (Level 2) requires verification 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.

V15.2.3 Production environment contains only required functionality

Requirement 15.2.3 (Level 2) requires verification 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.

V15.2.4 Third-party components from expected repository

Requirement 15.2.4 (Level 3) requires verification 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.

V15.2.5 Protections around dangerous functionality and risky components

Requirement 15.2.5 (Level 3) requires verification 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.

V15.3.1 Return only required subset of data object fields

Requirement 15.3.1 (Level 1) requires verification that the application only returns the required subset of fields from a data object and does not return an entire data object, as some individual fields should not be accessible to users.

V15.3.2 Backend external URL redirect handling

Requirement 15.3.2 (Level 2) requires verification that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality.

V15.3.3 Countermeasures against mass assignment attacks

Requirement 15.3.3 (Level 2) requires verification that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, ensuring it is not possible to insert or update a field value when it was not intended to be part of that action.

V15.3.4 Original IP address preservation through proxy and middleware

Requirement 15.3.4 (Level 2) requires verification 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. The application and web server must use this correct value for logging and security decisions such as rate limiting, with the understanding that even the original IP address may not be reliable due to dynamic IPs, VPNs, or corporate firewalls.

V15.3.5 Explicit type checking and strict equality operations

Requirement 15.3.5 (Level 2) requires verification that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations to avoid type juggling or type confusion vulnerabilities.

V15.3.6 JavaScript prototype pollution prevention

Requirement 15.3.6 (Level 2) requires verification that JavaScript code is written in a way that prevents prototype pollution, for example by using Set() or Map() instead of object literals.

V15.3.7 Defenses against HTTP parameter pollution

Requirement 15.3.7 (Level 2) requires verification that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters such as query string, body parameters, cookies, or header fields.

V15.4.1 Thread-safe access to shared multi-threaded objects

Requirement 15.4.1 (Level 3) requires verification 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.

V15.4.2 Atomic operations to prevent TOCTOU race conditions

Requirement 15.4.2 (Level 3) requires verification 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, such as checking if a file exists before opening it or verifying a user's access before granting it.

V15.4.3 Consistent lock usage to prevent deadlock and livelock

Requirement 15.4.3 (Level 3) requires verification that locks are used consistently to avoid threads getting stuck either 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.

V15.4.4 Resource allocation policies prevent thread starvation

Requirement 15.4.4 (Level 3) requires verification that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools and allowing lower-priority threads to proceed within a reasonable timeframe.

V15 definition of dangerous functionality

A component with dangerous functionality may be an internally developed or third-party component that performs operations such as deserialization of untrusted data, raw file or binary data parsing, dynamic code execution, or direct memory manipulation. Vulnerabilities in these types of operations pose a high risk of compromising the application and potentially exposing its underlying infrastructure.

V15 definition of risky component

A risky component is a third-party library (not internally developed) with missing or poorly implemented security controls around its development processes or functionality. Examples include components that are poorly maintained, unsupported, at the end-of-life stage, or have a history of significant vulnerabilities.

Security controls centralization principle

Security controls should be centralized, simple (economy of design), verifiably secure, and reusable. This principle should avoid duplicate, missing, or ineffective controls. This is a software security principle from ASVS 5.0 that is recommended but not a requirement.

Reuse well-vetted security controls principle

Wherever possible, use previously written and well-vetted security control implementations rather than relying on implementing controls from scratch. This is a software security principle from ASVS 5.0.

Give your agent this brain