Most injection and XSS flaws come from untrusted data reaching an interpreter in the wrong form; this chapter sets out where encoding, sanitization and safe deserialization must happen.
- Decode input once, and encode output as close as possible to the interpreter that will consume it.
- Use parameterized queries and safe APIs for SQL, operating-system commands and other interpreters.
- Sanitize rich content with maintained libraries, avoid
evaland user-supplied templates, and defend against SSRF. - Use memory-safe string handling in unmanaged code, and deserialize untrusted data only into allowed types.
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-1.1.1.
V1.1 Encoding and Sanitization Architecture · 2 requirements
For the whole section: Validate input safely and prevent regex denial of service (guide)
V1.1.1 Level 2
Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization.
V1.1.2 Level 2
Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself.
V1.2 Injection Prevention · 10 requirements
For the whole section: Prevent CRLF header injection, log forging and CSV formula injection (guide) · Prevent DOM XSS, postMessage abuse and client-side injection (guide) · Prevent NoSQL, LDAP, XPath and expression-language injection (guide) · Validate input safely and prevent regex denial of service (guide) · Secure design patterns: a catalogue for insecure-design (A06) (guide)
V1.2.1 Level 1
Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure.
On this site: Prevent XSS at the output boundary (guide) · CRLF injection in logs and response headers (fix card)
V1.2.2 Level 1
Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:).
On this site: Prevent XSS at the output boundary (guide)
V1.2.3 Level 1
Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection).
V1.2.4 Level 1
Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures.
On this site: Fix SQL injection in Python sqlite3 (guide) · Keep untrusted values out of executable syntax (guide) · Keep generated output out of executable contexts (guide) · NoSQL operator injection (fix card)
V1.2.5 Level 1
Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.
On this site: Keep untrusted values out of executable syntax (guide) · Run external programs without command or argument injection (guide) · ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat (guide) · Keep generated output out of executable contexts (guide) · Harden GitHub Actions against workflow and supply-chain attacks (guide)
V1.2.6 Level 2
Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.
On this site: Keep untrusted values out of executable syntax (guide) · LDAP filter injection (fix card)
V1.2.7 Level 2
Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries.
On this site: XPath injection (fix card)
V1.2.8 Level 2
Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks.
On this site: Run external programs without command or argument injection (guide)
V1.2.9 Level 2
Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters.
V1.2.10 Level 3
Verify that the application is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with a single quote if they appear as the first character in a field value.
On this site: CSV formula injection (fix card)
V1.3 Sanitization · 12 requirements
For the whole section: Prevent DOM XSS, postMessage abuse and client-side injection (guide) · Prevent NoSQL, LDAP, XPath and expression-language injection (guide) · Validate input safely and prevent regex denial of service (guide) · Secure design patterns: a catalogue for insecure-design (A06) (guide)
V1.3.1 Level 1
Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature.
On this site: Prevent XSS at the output boundary (guide) · Render rich text without granting it application privileges (guide) · Keep generated output out of executable contexts (guide)
V1.3.2 Level 1
Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed.
On this site: Keep untrusted values out of executable syntax (guide) · Keep untrusted input out of eval, expression languages and templates (guide) · Prevent file inclusion: LFI, RFI, dynamic imports and template names (guide) · Code injection (fix card)
V1.3.3 Level 2
Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long.
On this site: CRLF injection in logs and response headers (fix card)
V1.3.4 Level 2
Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain scripts and foreignObject.
V1.3.5 Level 2
Verify that the application sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.
On this site: Render rich text without granting it application privileges (guide)
V1.3.6 Level 2
Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service.
On this site: Constrain server-side fetches to their intended destinations (guide) · Consume third-party APIs safely (OWASP API10:2023) (guide) · Call a hosted LLM API safely (guide)
V1.3.7 Level 2
Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated.
On this site: Keep untrusted values out of executable syntax (guide) · Keep untrusted input out of eval, expression languages and templates (guide) · Prevent file inclusion: LFI, RFI, dynamic imports and template names (guide)
V1.3.8 Level 2
Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured securely to prevent JNDI injection attacks.
V1.3.9 Level 2
Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks.
V1.3.10 Level 2
Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed.
V1.3.11 Level 2
Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
V1.3.12 Level 3
Verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks.
V1.4 Memory, String, and Unmanaged Code · 3 requirements
For the whole section: Find, fix and contain memory-safety bugs in C and C++ (guide) · Audit unsafe Rust, FFI boundaries and crate dependencies (guide)
V1.4.1 Level 2
Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.
On this site: Fuzz a parser and turn crashes into lasting regressions (guide)
V1.4.2 Level 2
Verify that sign, range, and input validation techniques are used to prevent integer overflows.
On this site: Fuzz a parser and turn crashes into lasting regressions (guide)
V1.4.3 Level 2
Verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities.
V1.5 Safe Deserialization · 3 requirements
V1.5.1 Level 1
Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.
On this site: Keep untrusted values out of executable syntax (guide) · Convert untrusted office documents and PDFs in an isolated parser (guide) · Parse bounded JSON and XML into an explicit application schema (guide)
V1.5.2 Level 2
Verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure must not be used with untrusted input.
On this site: Keep untrusted values out of executable syntax (guide) · Treat model releases as executable supply-chain inputs (guide) · Parse bounded JSON and XML into an explicit application schema (guide)
V1.5.3 Level 3
Verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks.
On this site: Parse bounded JSON and XML into an explicit application schema (guide)
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
Fix SQL injection in Python sqlite3
Bind query values separately from SQL syntax, then prove the fix preserves legitimate behavior and blocks an injection probe.
Prevent XSS at the output boundary
Choose text rendering, context-aware encoding, or deliberate HTML sanitization according to how the browser will interpret the value.
Render rich text without granting it application privileges
Choose text rendering or a restricted HTML policy, then test the final DOM after every transformation.
Keep untrusted values out of executable syntax
Choose a safe interface for each interpreter and bound the work performed by parsers and converters.
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.
Keep generated output out of executable contexts
Choose safe rendering and narrow operations so model text cannot become browser code, database syntax or an unrestricted command.
Constrain server-side fetches to their intended destinations
Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.
Fuzz a parser and turn crashes into lasting regressions
Build a narrow harness, observe memory and resource failures, minimize the input, and test the repaired parser.
ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat
Scope edition-qualified requirements, connect them to implementation and tests, and separate a passing check from an unsupported assurance claim.
Combine static and dynamic tests around a verified finding
Use analysis tools to find evidence, then retain an application regression that demonstrates the failure and the fix.
Run external programs without command or argument injection
Run programs from an argument list with no shell, end options before user values, and keep untrusted arguments away from Windows batch files.
Keep untrusted input out of eval, expression languages and templates
Keep code and templates constant, pass input as data, and treat in-process sandboxes as one layer, not a boundary.
Practice
- XSS lab: Render a model’s answer as text instead of active markup · Browser lab
- Release evidence lab: Keep stale test evidence out of a release decision · Browser lab
- SSRF lab: Guard an outbound fetch against SSRF · Browser lab
- HTML sanitization lab: Configure a sanitizer for user comments · Browser lab
- SQL injection lab: Separate SQL structure from data with sqlite3 · Browser lab
- SSRF validation lab: Validate a fetch URL with ipaddress · Browser lab
- OS command injection lab: Run git without a shell · Browser lab
- SSTI lab: Render a welcome banner without template injection · Browser lab
- XXE lab: Parse an uploaded invoice without resolving external entities · Browser lab
- Pickle deserialization lab: Load a session token without pickle · Browser lab
- Parse bounded JSON and XML invoices safely · Local project
- Repair a native parser using sanitizer evidence · Local project
- Run model-generated Python in a locked-down container · Local project
References
- V1 Encoding and Sanitization (ASVS 5.0.0 source)
- OWASP LDAP Injection Prevention Cheat Sheet
- OWASP Cross Site Scripting Prevention Cheat Sheet
- OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet
- OWASP XML External Entity Prevention Cheat Sheet
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.