Cryptography, TLS, and Configuration Hardening — ASVS 5.0 V11, V12 & V13

OWASP ASVS 5.0 spans seventeen chapters. Most of the conversation around it focuses on injection (V1), authentication (V6), and authorization (V8) — the layers closest to user-facing functionality. Chapters V11, V12, and V13 sit beneath all of that. They define the cryptographic primitives the rest of the application depends on, the transport security every connection runs over, and the deployment configuration that determines what the application reveals about itself. Getting these wrong undermines everything built on top of them.

This article works through each chapter in the order they appear in the standard, then examines how the three chapters compose into a coherent infrastructure security baseline.

V11 — Cryptography

Algorithm approval and deprecation

ASVS 5.0 takes a clear position: use industry-validated library implementations, not custom code, and use only approved primitives. The approval question breaks down across three categories.

Symmetric encryption

Authenticated encryption is the default expectation. AES-GCM is the canonical approved mode (requirement 11.3.2). ECB mode is prohibited at Level 1 — there is no assurance level at which ECB is acceptable (11.3.1). The requirement is precise: it bans not just ECB but also weak padding schemes such as PKCS#1 v1.5. The underlying issue is that ECB produces identical ciphertext blocks for identical plaintext blocks, and PKCS#1 v1.5 padding on RSA encryption creates conditions for padding oracle attacks.

ChaCha20 (as ChaCha20-Poly1305) is included in the approved list alongside AES-GCM via the Appendix C reference. Both provide authenticated encryption; both are acceptable. What is not acceptable is using an unauthenticated cipher (AES-CBC, AES-CTR) without pairing it with an approved MAC algorithm, and even then, the combination must operate in encrypt-then-MAC order, not MAC-then-encrypt (11.3.5).

Hash functions

MD5 and SHA-1 are prohibited for any cryptographic purpose (11.4.1). The prohibition is not qualified — there is no legacy or non-security-critical exemption. For digital signatures and data authentication, hash functions must be collision-resistant with at least 256-bit output. Where only second pre-image resistance is needed, 128-bit output is the floor (11.4.3).

SHA-256, SHA-384, SHA-512, and SHA-3 variants are all in scope as approved. MD5 and SHA-1 are not.

DES and 3DES are addressed through the key-length floor in 11.2.3: all cryptographic primitives must deliver at least 128 bits of security. DES provides 56 bits and is trivially broken; 3DES provides roughly 112 bits of effective security in its strongest configuration (three independent keys), which falls short. Neither is usable.

RSA key lengths

The 128-bit security equivalence table in requirement 11.2.3 is explicit: a 256-bit ECC key delivers approximately 128 bits of security; RSA requires 3072 bits to reach the same level. A 2048-bit RSA key provides approximately 112 bits of security and does not satisfy the 128-bit floor. The minimum RSA key size under ASVS 5.0 is therefore 3072 bits.

Random number generation

Section V11.5 addresses CSPRNG use directly. Requirement 11.5.1 sets two conditions: non-guessable values must come from a CSPRNG, and they must carry at least 128 bits of entropy.

The explicit callout that UUIDs do not satisfy this requirement deserves attention. UUID v4 is generated from 122 bits of randomness, which is close to 128 bits but the broader UUID family (v1, v3, v5) includes time-based and name-based variants that are either guessable or deterministic. ASVS draws a hard line: do not rely on UUID as a CSPRNG output for security-sensitive values.

What "cryptographically secure" means in practice: a CSPRNG must produce output that is computationally indistinguishable from random, must be seeded from a high-entropy source (OS entropy pool — /dev/urandom on Linux, CryptGenRandom on Windows, SecureRandom in the JVM), and must not be the application-layer Math.random() or equivalent. In most languages, the right call is straightforward:

• Go: crypto/rand.Read()
• Python: secrets.token_bytes()
• Node.js: crypto.randomBytes()
• Java: SecureRandom (not Random)

Requirement 11.5.2 adds a resilience dimension at Level 3: the CSPRNG must continue to operate securely under high demand. This rules out entropy-depleting designs where a busy system produces predictable output because its entropy pool has been exhausted.

Key management

The key management requirements in V11.1 are structured around a formal policy aligned to NIST SP 800-57, covering the full key lifecycle: generation, distribution, storage, use, rotation, and destruction.

Separation of keys by purpose

Requirement 11.1.2 mandates a cryptographic inventory that documents not only what keys exist but where they can and cannot be used, and what data types they can and cannot protect. Keys must be purpose-bound. An encryption key used for data at rest must not double as a signing key; a key used for one service must not be shared with another.

The sharing constraints are specific: shared secrets can be shared by at most two entities; private keys must be held by exactly one entity. There is no legitimate "admin has a copy of all private keys" configuration under this model.

Key storage — hardcoded keys are prohibited

Requirement 13.3.1 (in V13 Secret Management, which addresses the operational side) is unambiguous: secrets, including key material, must not appear in source code or build artifacts. They must be managed through a dedicated secrets vault or key management service. At Level 3, this must involve a hardware-backed solution — an HSM or hardware-backed KMS.

The corollary: environment variable files checked into version control, .env files in container images, and API keys embedded in application binaries all violate this requirement.

Key rotation

Rotation must be possible by design. Requirement 11.2.2 mandates crypto agility — the application must be architected so that algorithms, key lengths, and keys themselves can be swapped without breaking the system. Requirement 13.3.4 requires rotation schedules to be documented and enforced. A key that has never been rotated and has no rotation procedure is a compliance gap at Level 2 and above.

Crypto agility and post-quantum preparedness

Requirement 11.2.2 introduces crypto agility as a design requirement: the application must support swapping algorithms, keys, and cipher configurations without architectural changes. This is forward-looking — specifically, it enables migration to post-quantum cryptography (PQC) when high-assurance implementations become widely available.

At Level 3, requirement 11.1.4 adds a documented PQC migration plan to the cryptographic inventory. RSA and ECDH are quantum-vulnerable; a system with no migration path is not considered future-proof under the standard.

V12 — Secure Communication

TLS version and cipher suite requirements

Requirement 12.1.1 sets the floor at TLS 1.2, with TLS 1.3 as the preferred version. TLS 1.0 and 1.1 are not mentioned as acceptable at any level — they are simply absent from the approved list.

The practical implication: any server configuration that retains TLS 1.0 or TLS 1.1 for backward compatibility fails this requirement. The tooling to verify this is widely available — Mozilla Observatory, testssl.sh, and the TLS scanner in most modern vulnerability scanners all flag deprecated protocol versions.

Cipher suites

Requirement 12.1.2 requires only recommended cipher suites, with the strongest set as preferred. At Level 3, cipher suites that do not provide forward secrecy are prohibited. Forward secrecy (via ECDHE or DHE key exchange) ensures that compromising a long-term private key does not retroactively expose past sessions.

The practical cipher suite consequence: static RSA key exchange (TLS_RSA_*) cipher suites must not be present in Level 3 configurations. TLS 1.3 solves this by design — it only supports forward-secret key exchange, which is one of the reasons requirement 12.1.1 positions TLS 1.3 as the preferred version.

Certificate validation and management

External-facing services

Requirements 12.2.1 and 12.2.2 form the baseline for external-facing HTTP: all traffic must be TLS with no cleartext fallback, and certificates must be publicly trusted. Self-signed certificates are not acceptable for external endpoints.

Certificate revocation

Requirement 12.1.4 at Level 3 requires OCSP Stapling. Standard OCSP requires the client to contact the CA's revocation server during every TLS handshake, adding latency and a third-party dependency. Stapling shifts this: the server periodically fetches and caches a signed OCSP response and staples it into the TLS handshake. The client gets freshness without contacting the CA directly.

Certificate pinning

ASVS 5.0 does not mandate certificate pinning for general use. Pinning is referenced in the context of mTLS client certificate validation (12.1.3) and internal service trust anchors (12.3.4). The historical lesson with public key pinning (HPKP) is instructive: it was deprecated by browsers because misconfiguration rendered sites permanently inaccessible. ASVS takes the measured position — validate certificates against trusted CAs; for internal services where self-signed certificates are used, pin to specific internal CAs or certificates rather than public CAs (12.3.4).

HSTS

HSTS configuration lives in V3 (Web Frontend Security) rather than V12. Chapter V3 requires Strict-Transport-Security with a minimum max-age of one year, with includeSubDomains added from Level 2. The mechanism — once a browser sees the HSTS header over a valid HTTPS connection, it will refuse to connect over plain HTTP for the duration of the max-age — provides defense against SSL stripping attacks that TLS configuration alone cannot prevent.

Encrypted Client Hello

Requirement 12.1.5 at Level 3 adds ECH (Encrypted Client Hello). The standard TLS handshake sends the SNI field in plaintext, revealing the target hostname to network observers even when the connection content is encrypted. ECH encrypts the ClientHello — including the SNI — using a public key published in the server's DNS record. This is a relatively recent addition to the TLS stack; production support is available in BoringSSL/OpenSSL 3.x and recent versions of nginx and Caddy.

Internal service-to-service TLS

This is where ASVS 5.0 extends beyond the obvious. Requirement 12.3.1 is broad: all inbound and outbound connections — monitoring systems, management tools, SSH, middleware, databases, mainframes, partner APIs — must use TLS or equivalent encryption with no cleartext fallback. The perimeter is not the network edge; it is every connection the application makes.

Requirement 12.3.3 specifically addresses internal HTTP connections between microservices. Plain HTTP between services inside a Kubernetes cluster or a VPC fails this requirement. The "we're inside the network boundary" justification is not a valid exemption.

Internal certificate management

Requirement 12.3.4 addresses the trust anchor for internal TLS. Where self-signed certificates are used between internal services, the consuming service must be configured to trust only specific internal CAs or specific named certificates — not the OS trust store, which would accept any publicly trusted certificate. This prevents an attacker with a publicly trusted certificate from impersonating an internal service.

At Level 3, requirement 12.3.5 adds mutual TLS for intra-service communication: each endpoint must authenticate to the other using TLS client certificates, backed by a PKI, with replay-attack resistance. For microservice environments, the standard notes that a service mesh (Istio, Linkerd, Consul Connect) simplifies this significantly — automatic mTLS between all pods removes the need to manage client certificates in application code.

V13 — Configuration

Security headers

Security headers are split across V3 (browser-facing) and V13 (deployment configuration). The full set required by ASVS 5.0:

A few specifics worth noting:

• X-Frame-Options is explicitly marked as obsolete in ASVS 5.0. The frame-ancestors CSP directive is the required replacement, and it is more expressive — it supports multiple origins and 'none' as a value.
• Referrer-Policy must prevent sensitive URL data from reaching third parties. strict-origin-when-cross-origin or no-referrer are the appropriate values for most applications; unsafe-url fails this requirement.
• Permissions-Policy restricts access to browser APIs (camera, microphone, geolocation, payment). Applications that do not use these APIs should restrict them explicitly rather than leaving browser defaults in place.

Build and deployment configuration

Section V13.4 (Unintended Information Leakage) covers the hardening steps that individually look minor but collectively raise the cost of reconnaissance:

• Source control metadata (13.4.1): .git and .svn directories must not be accessible in production. A publicly accessible .git/ directory exposes the entire commit history, configuration files, and potentially credentials.
• Debug mode off (13.4.2): Debug modes must be disabled for all components in production. This covers framework-level debug flags (DEBUG=True in Django, development in Express, verbose error output in Spring Boot).
• Stack traces off (V16.5, cross-reference): Unhandled exceptions must return generic messages. Stack traces, SQL queries, and internal paths must not appear in HTTP responses.
• Directory listing off (13.4.3): Web servers must not serve directory listings unless explicitly configured to do so. Nginx, Apache, and S3-hosted static sites all have different defaults here.
• HTTP TRACE disabled (13.4.4): The TRACE method echoes the request back to the sender, which can expose authentication headers to cross-site scripting vectors.
• Version information suppressed (13.4.6 at Level 3): Server version strings in Server: and X-Powered-By: headers must not be present.
• File extension filtering (13.4.7 at Level 3): The web tier must only serve files with permitted extensions, preventing accidental exposure of configuration files, source code, or backup files that end up in a web-accessible directory.

Dependency management

Dependency hygiene under ASVS 5.0 is primarily addressed in V15 (Secure Coding and Architecture), but V13's configuration requirements interact with it directly. Requirement 13.3.1 prohibits secrets in build artifacts, which includes container images — base images with embedded credentials or default configurations are covered here.

V15 requires maintaining an SBOM, updating components within documented remediation timeframes, and mitigating dependency confusion attacks (where a malicious package with the same name as an internal package is published to a public registry). The V13 connection: the build process must not introduce components that violate the configuration standards set in V13. Debug stubs, test endpoints, and sample applications from third-party frameworks must be absent from production builds (V15.2).

Secret management

Section V13.3 establishes the operational requirements for secrets — credentials, API keys, database passwords, key material, and token seeds. The minimum standard (Level 2):

• Use a dedicated secrets vault or key management service.
• Secrets must not appear in source code, build artifacts, environment variable files, or container images.
• Access to secrets must follow least-privilege principles.

At Level 3, all cryptographic operations must run through an isolated security module (vault or HSM), and secrets must be configured to expire and rotate on documented schedules (13.3.4).

The practical consequence: applications that read credentials from .env files at startup or use long-lived API keys embedded in configuration fail this at Level 2. The expected pattern is dynamic secret injection at runtime from a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), with short-lived credentials where the service supports them.

V11, V12, and V13 as an infrastructure layer

The three chapters are structured as foundations. V11 defines the cryptographic primitives used everywhere else in the application: password hashing (bcrypt/Argon2id, required by 11.4.2), session token generation (CSPRNG, 128-bit entropy, required by 11.5.1 and cross-referenced from V7), and the signing algorithms behind JWT validation (approved hash functions, 11.4.1) and certificate handling (RSA key lengths, 11.2.3).

V12 defines the transport layer those primitives run over. The requirement that internal services use TLS with mutual authentication (12.3.5) only means something if the certificates involved are generated using approved algorithms from V11 and managed under the key lifecycle policy from V11.1.

V13 defines the configuration envelope: how secrets get into the application without appearing in source code or build artifacts (V13.3), how the application avoids disclosing its internal structure to unauthenticated clients (V13.4), and how backend service connections are authenticated and least-privileged (V13.2). These constraints apply equally to the cryptographic material managed under V11 and the TLS infrastructure required by V12.

The implication for platform and DevOps teams: these three chapters are not application-developer concerns delegated to security reviews. They are infrastructure requirements that must be present before application-layer features are built. A deployment pipeline that does not enforce TLS between services (V12), does not inject secrets from a vault (V13.3), and does not validate its cryptographic configuration against the approved algorithm list (V11) fails the ASVS baseline regardless of how carefully the application-layer code handles input validation or session management.

Verifying compliance with V11, V12, and V13 requires tooling at the infrastructure level: TLS scanners, secrets detection in CI pipelines, SBOM generation, and cryptographic inventory tooling. The OWASP Web Security Testing Guide and Mozilla's TLS configuration generator are the standard starting points for the V12 side; Appendix C of ASVS 5.0 itself provides the approved algorithm reference for V11.