+V15 Secure Coding and Architecture
---+V15.1 Secure Coding and Architecture Documentation
------+V15.1.1 Verify that application documentation defines risk based remediation time frames for 3rd party …
------+V15.1.2 Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all …
------+V15.1.3 Verify that the application documentation identifies functionality which is time-consuming or …
------+V15.1.4 Verify that application documentation highlights third-party libraries which are considered to be …
------+V15.1.5 Verify that application documentation highlights parts of the application where "dangerous …
---+V15.2 Security Architecture and Dependencies
------+V15.2.1 Verify that the application only contains components which have not breached the documented update …
------+V15.2.2 Verify that the application has implemented defenses against loss of availability due to …
------+V15.2.3 Verify that the production environment only includes functionality that is required for the …
------+V15.2.4 Verify that third-party components and all of their transitive dependencies are included from the …
------+V15.2.5 Verify that the application implements additional protections around parts of the application which …
---+V15.3 Defensive Coding
------+V15.3.1 Verify that the application only returns the required subset of fields from a data object. For …
------+V15.3.2 Verify that where the application backend makes calls to external URLs, it is configured to not …
------+V15.3.3 Verify that the application has countermeasures to protect against mass assignment attacks by …
------+V15.3.4 Verify that all proxying and middleware components transfer the user's original IP address …
------+V15.3.5 Verify that the application explicitly ensures that variables are of the correct type and performs …
------+V15.3.6 Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by …
------+V15.3.7 Verify that the application has defenses against HTTP parameter pollution attacks, particularly if …
---+V15.4 Safe Concurrency
------+V15.4.1 Verify that shared objects in multi-threaded code (such as caches, files, or in-memory objects …
------+V15.4.2 Verify that checks on a resource's state, such as its existence or permissions, and the actions …
------+V15.4.3 Verify that locks are used consistently to avoid threads getting stuck, whether by waiting on each …
------+V15.4.4 Verify that resource allocation policies prevent thread starvation by ensuring fair access to …

V15 Secure Coding and Architecture

Control Objective

Many ASVS requirements either relate to a particular area of security, such as authentication or authorization, or pertain to a particular type of application functionality, such as logging or file handling.

This chapter provides general security requirements to consider when designing and developing applications. These requirements focus not only on clean architecture and code quality but also on specific architecture and coding practices necessary for application security.

References

For more information, see also:

1. Pārskats

Nosaukums Standarts
V15.1 Secure Coding and Architecture Documentation

Many requirements for establishing a secure and defensible architecture depend on clear documentation of decisions made regarding the implementation of specific security controls and the components used within the application.

This section outlines the documentation requirements, including identifying components considered to contain "dangerous functionality" or to be "risky components."

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.

A "risky component" is a 3rd party library (i.e., 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.

This section also emphasizes the importance of defining appropriate timeframes for addressing vulnerabilities in third-party components.

V15.2 Security Architecture and Dependencies

This section includes requirements for handling risky, outdated, or insecure dependencies and components through dependency management.

It also includes using architectural-level techniques such as sandboxing, encapsulation, containerization, and network isolation to reduce the impact of using "dangerous operations" or "risky components" (as defined in the previous section) and prevent loss of availability due to overusing resource-demanding functionality.

V15.3 Defensive Coding

This section covers vulnerability types, including type juggling, prototype pollution, and others, which result from using insecure coding patterns in a particular language. Some may not be relevant to all languages, whereas others will have language-specific fixes or may relate to how a particular language or framework handles a feature such as HTTP parameters. It also considers the risk of not cryptographically validating application updates.

It also considers the risks associated with using objects to represent data items and accepting and returning these via external APIs. In this case, the application must ensure that data fields that should not be writable are not modified by user input (mass assignment) and that the API is selective about what data fields get returned. Where field access depends on a user's permissions, this should be considered in the context of the field-level access control requirement in the Authorization chapter.

V15.4 Safe Concurrency

Concurrency issues such as race conditions, time-of-check to time-of-use (TOCTOU) vulnerabilities, deadlocks, livelocks, thread starvation, and improper synchronization can lead to unpredictable behavior and security risks. This section includes various techniques and strategies to help mitigate these risks.

1.1 Atsauces

1.2 Identificētās prasības

1.3 Saistītie tiesību akti

2. Identificētās prasības

Prasības
Avots Prasība

3. Saistītie tiesību akti

Tiesību akti
Avots Regulējums
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.