Secrets, backend connections and deployment settings decide how much a single compromise exposes; leaked secrets and leftover debug features are common ways in.
- Document each service’s communication needs and resource limits.
- Authenticate backend connections with individual, least-privilege accounts.
- Keep secrets in a secrets manager, never in code or configuration files, and rotate them.
- Remove debug features, directory listings and unnecessary information from production.
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-13.1.1.
V13.1 Configuration Documentation · 4 requirements
V13.1.1 Level 2
Verify that all communication needs for the application are documented. This must include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect.
On this site: Consume third-party APIs safely (OWASP API10:2023) (guide) · Call a hosted LLM API safely (guide)
V13.1.2 Level 3
Verify that for each service the application uses, the documentation defines the maximum number of concurrent connections (e.g., connection pool limits) and how the application behaves when that limit is reached, including any fallback or recovery mechanisms, to prevent denial of service conditions.
V13.1.3 Level 3
Verify that the application documentation defines resource‑management strategies for every external system or service it uses (e.g., databases, file handles, threads, HTTP connections). This should include resource‑release procedures, timeout settings, failure handling, and where retry logic is implemented, specifying retry limits, delays, and back‑off algorithms. For synchronous HTTP request–response operations it should mandate short timeouts and either disable retries or strictly limit retries to prevent cascading delays and resource exhaustion.
V13.1.4 Level 3
Verify that the application's documentation defines the secrets that are critical for the security of the application and a schedule for rotating them, based on the organization's threat model and business requirements.
On this site: Secrets management: storage, rotation and leaked-secret response (guide)
V13.2 Backend Communication Configuration · 6 requirements
For the whole section: Apply a security baseline across AWS, Azure and Google Cloud (guide) · Contain a leaked secret, then investigate and clean up (guide)
V13.2.1 Level 2
Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated. Authentication must use individual service accounts, short-term tokens, or certificate-based authentication and not unchanging credentials such as passwords, API keys, or shared accounts with privileged access.
On this site: Workload identity federation: short-lived, scoped identities for services and CI (guide) · Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS (guide) · Case study: the CircleCI security incident (January 2023) (guide) · Missing authentication for a critical function (fix card)
V13.2.2 Level 2
Verify that communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are performed with accounts assigned the least necessary privileges.
On this site: Review infrastructure changes as access changes (guide) · Workload identity federation: short-lived, scoped identities for services and CI (guide)
V13.2.3 Level 2
Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin).
V13.2.4 Level 2
Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound requests, data loads, or file access). This allowlist can be implemented at the application layer, web server, firewall, or a combination of different layers.
On this site: Constrain server-side fetches to their intended destinations (guide) · Sandbox model-generated code and computer-use agents (guide)
V13.2.5 Level 2
Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from.
V13.2.6 Level 3
Verify that where the application connects to separate services, it follows the documented configuration for each connection, such as maximum parallel connections, behavior when maximum allowed connections is reached, connection timeouts, and retry strategies.
V13.3 Secret Management · 4 requirements
For the whole section: Place each security control in the pipeline and decide what it blocks (guide) · Case study: the Shai-Hulud npm worm (2025-2026) (guide) · Case study: the tj-actions/changed-files compromise (CVE-2025-30066) (guide) · Apply a security baseline across AWS, Azure and Google Cloud (guide) · Contain a leaked secret, then investigate and clean up (guide)
V13.3.1 Level 2
Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets. These could include passwords, key material, integrations with databases and third-party systems, keys and seeds for time-based tokens, other internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For an L3 application, this must involve a hardware-backed solution such as an HSM.
On this site: Review infrastructure changes as access changes (guide) · Secrets management: storage, rotation and leaked-secret response (guide) · Envelope encryption and key rotation: data keys, KMS keys and backups (guide) · Workload identity federation: short-lived, scoped identities for services and CI (guide) · Harden GitHub Actions against workflow and supply-chain attacks (guide) · Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS (guide) · Case study: the LastPass breach (2022) (guide) · Keep secrets and controls out of hidden context (OWASP LLM08:2026) (guide) · Case study: the CircleCI security incident (January 2023) (guide) · Hard-coded secrets (fix card)
V13.3.2 Level 2
Verify that access to secret assets adheres to the principle of least privilege.
On this site: Review infrastructure changes as access changes (guide) · Secrets management: storage, rotation and leaked-secret response (guide) · Harden GitHub Actions against workflow and supply-chain attacks (guide) · Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS (guide) · Case study: the LastPass breach (2022) (guide) · Case study: Microsoft AI researchers' over-permissive SAS token (2023) (guide)
V13.3.3 Level 3
Verify that all cryptographic operations are performed using an isolated security module (such as a vault or hardware security module) to securely manage and protect key material from exposure outside of the security module.
On this site: Envelope encryption and key rotation: data keys, KMS keys and backups (guide)
V13.3.4 Level 3
Verify that secrets are configured to expire and be rotated based on the application's documentation.
On this site: Secrets management: storage, rotation and leaked-secret response (guide) · Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS (guide) · Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot (guide) · Case study: Storm-0558 and the forged Microsoft tokens (2023) (guide) · Case study: Microsoft AI researchers' over-permissive SAS token (2023) (guide)
V13.4 Unintended Information Leakage · 7 requirements
For the whole section: Ship without debug modes, verbose errors or exposed files (guide)
V13.4.1 Level 1
Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself.
V13.4.2 Level 2
Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage.
On this site: Handle failures without leaking internals or weakening controls (guide) · Preserve framework security controls across the request lifecycle (guide)
V13.4.3 Level 2
Verify that web servers do not expose directory listings to clients unless explicitly intended.
V13.4.4 Level 2
Verify that using the HTTP TRACE method is not supported in production environments, to avoid potential information leakage.
V13.4.5 Level 2
Verify that documentation (such as for internal APIs) and monitoring endpoints are not exposed unless explicitly intended.
V13.4.6 Level 3
Verify that the application does not expose detailed version information of backend components.
V13.4.7 Level 3
Verify that the web tier is configured to only serve files with specific file extensions to prevent unintentional information, configuration, and source code leakage.
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
Secrets management: storage, rotation and leaked-secret response
Follow one application credential from issuance through caching, rotation, revocation and restored backups, prove that its old value stops working, and respond correctly when a secret leaks.
Workload identity federation: short-lived, scoped identities for services and CI
Trace how a running workload obtains a short-lived identity, write cloud trust policies that match immutable claims instead of names or wildcards, and keep the resulting credential limited by audience and authorization.
Ship without debug modes, verbose errors or exposed files
Turn off debug output, publish an allowlisted build and probe each deployment for exposed files and endpoints.
Review infrastructure changes as access changes
Inspect the effective permissions, exposure, sensitive state, and recovery implications of a proposed infrastructure change.
Envelope encryption and key rotation: data keys, KMS keys and backups
Encrypt each record with its own data key, wrap that key in a KMS or HSM key, and keep wrapping-key rotation, data re-encryption, key deletion and restored backups as separate, tested operations.
Authenticate workloads and authorize their service actions
Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization.
Preserve framework security controls across the request lifecycle
Trace middleware, persistence and rendering so custom code does not bypass the protections supplied by the framework.
Constrain server-side fetches to their intended destinations
Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.
Practice
- SSRF lab: Guard an outbound fetch against SSRF · Browser lab
- SSRF validation lab: Validate a fetch URL with ipaddress · Browser lab
- Insecure randomness lab: Generate unguessable API keys · Browser lab
- Secure a real HTTP API · Local project
- Bind ciphertext to the correct record · Local project
References
- V13 Configuration (ASVS 5.0.0 source)
- OWASP Web Security Testing Guide: Configuration and Deployment Management Testing
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.