+V1 Encoding and Sanitization
---+V1.1 Encoding and Sanitization Architecture
------+V1.1.1 Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when …
------+V1.1.2 Verify that the application performs output encoding and escaping either as a final step before …
---+V1.2 Injection Prevention
------+V1.2.1 Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for …
------+V1.2.2 Verify that when dynamically building URLs, untrusted data is encoded according to its context …
------+V1.2.3 Verify that output encoding or escaping is used when dynamically building JavaScript content …
------+V1.2.4 Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized …
------+V1.2.5 Verify that the application protects against OS command injection and that operating system calls …
------+V1.2.6 Verify that the application protects against LDAP injection vulnerabilities, or that specific …
------+V1.2.7 Verify that the application is protected against XPath injection attacks by using query …
------+V1.2.8 Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) …
------+V1.2.9 Verify that the application escapes special characters in regular expressions (typically using a …
------+V1.2.10 Verify that the application is protected against CSV and Formula Injection. The application must …
---+V1.3 Sanitization
------+V1.3.1 Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a …
------+V1.3.2 Verify that the application avoids the use of eval() or other dynamic code execution features such …
------+V1.3.3 Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce …
------+V1.3.4 Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or …
------+V1.3.5 Verify that the application sanitizes or disables user-supplied scriptable or expression template …
------+V1.3.6 Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by …
------+V1.3.7 Verify that the application protects against template injection attacks by not allowing templates …
------+V1.3.8 Verify that the application appropriately sanitizes untrusted input before use in Java Naming and …
------+V1.3.9 Verify that the application sanitizes content before it is sent to memcache to prevent injection …
------+V1.3.10 Verify that format strings which might resolve in an unexpected or malicious way when used are …
------+V1.3.11 Verify that the application sanitizes user input before passing to mail systems to protect against …
------+V1.3.12 Verify that regular expressions are free from elements causing exponential backtracking, and ensure …
---+V1.4 Memory, String, and Unmanaged Code
------+V1.4.1 Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to …
------+V1.4.2 Verify that sign, range, and input validation techniques are used to prevent integer overflows.
------+V1.4.3 Verify that dynamically allocated memory and resources are released, and that references or …
---+V1.5 Safe Deserialization
------+V1.5.1 Verify that the application configures XML parsers to use a restrictive configuration and that …
------+V1.5.2 Verify that deserialization of untrusted data enforces safe input handling, such as using an …
------+V1.5.3 Verify that different parsers used in the application for the same data type (e.g., JSON parsers …

V1 Encoding and Sanitization

Control Objective

This chapter addresses the most common web application security weaknesses related to the unsafe processing of untrusted data. Such weaknesses can result in various technical vulnerabilities, where untrusted data is interpreted according to the syntax rules of the relevant interpreter.

For modern web applications, it is always best to use safer APIs, such as parameterized queries, auto-escaping, or templating frameworks. Otherwise, carefully performed output encoding, escaping, or sanitization becomes critical to the application's security.

Input validation serves as a defense-in-depth mechanism to protect against unexpected or dangerous content. However, since its primary purpose is to ensure that incoming content matches functional and business expectations, requirements related to this can be found in the "Validation and Business Logic" chapter.

References

For more information, see also:

For more information, specifically on deserialization or parsing issues, please see:

1. Übersicht

Bezeichnung Standard
V1.1 Encoding and Sanitization Architecture

In the sections below, syntax-specific or interpreter-specific requirements for safely processing unsafe content to avoid security vulnerabilities are provided. The requirements in this section cover the order in which this processing should occur and where it should take place. They also aim to ensure that whenever data is stored, it remains in its original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues.

V1.2 Injection Prevention

Output encoding or escaping, performed close to or adjacent to a potentially dangerous context, is critical to the security of any application. Typically, output encoding and escaping are not persisted, but are instead used to render output safe for immediate use in the appropriate interpreter. Attempting to perform this too early may result in malformed content or render the encoding or escaping ineffective.

In many cases, software libraries include safe or safer functions that perform this automatically, although it is necessary to ensure that they are correct for the current context.

Note: Using parameterized queries or escaping SQL is not always sufficient. Query parts such as table and column names (including "ORDER BY" column names) cannot be escaped. Including escaped user-supplied data in these fields results in failed queries or SQL injection.

V1.3 Sanitization

The ideal protection against using untrusted content in an unsafe context is to use context-specific encoding or escaping, which maintains the same semantic meaning of the unsafe content but renders it safe for use in that particular context, as discussed in more detail in the previous section.

Where this is not possible, sanitization becomes necessary, removing potentially dangerous characters or content. In some cases, this may change the semantic meaning of the input, but for security reasons, there may be no alternative.

V1.4 Memory, String, and Unmanaged Code

The following requirements address risks associated with unsafe memory use, which generally apply when the application uses a systems language or unmanaged code.

In some cases, it may be possible to achieve this by setting compiler flags that enable buffer overflow protections and warnings, including stack randomization and data execution prevention, and that break the build if unsafe pointer, memory, format string, integer, or string operations are found.

V1.5 Safe Deserialization

The conversion of data from a stored or transmitted representation into actual application objects (deserialization) has historically been the cause of various code injection vulnerabilities. It is important to perform this process carefully and safely to avoid these types of issues.

In particular, certain methods of deserialization have been identified by programming language or framework documentation as insecure and cannot be made safe with untrusted data. For each mechanism in use, careful due diligence should be performed.

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.3 Zugehörige Regulierungen

2. Identifizierte Anforderungen

Anforderungen
Quelle Anforderung

3. Zugehörige Regulierungen

Regulierungen
Quelle Regulierung
  • 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.