Traffic between users and services, and between services, must be encrypted and authenticated; otherwise credentials and data are exposed on the network.
- Enable only current TLS versions and strong cipher suites.
- Use publicly trusted certificates for external services, and validate certificates on internal connections.
- Encrypt and authenticate service-to-service traffic, for example with mutual TLS.
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-12.1.1.
V12.1 General TLS Security Guidance · 5 requirements
For the whole section: Choose cryptographic algorithms and parameters by job (guide)
V12.1.1 Level 1
Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option.
On this site: Lucky Thirteen and POODLE: two different oracles (guide) · FREAK and Logjam: export-grade key exchange (guide) · DROWN: one RSA key across incompatible protocols (guide) · Operate TLS and certificates: configuration, renewal and verification (guide) · Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot (guide)
V12.1.2 Level 2
Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy.
On this site: RC4 keystream bias (guide) · 64-bit block ciphers and the Sweet32 mechanism (guide) · Lucky Thirteen and POODLE: two different oracles (guide) · FREAK and Logjam: export-grade key exchange (guide) · DROWN: one RSA key across incompatible protocols (guide) · Sweet32: the cost of a small block size (guide) · Operate TLS and certificates: configuration, renewal and verification (guide)
V12.1.3 Level 2
Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization.
V12.1.4 Level 3
Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.
V12.1.5 Level 3
Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes.
V12.2 HTTPS Communication with External Facing Services · 2 requirements
V12.2.1 Level 1
Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications.
V12.2.2 Level 1
Verify that external facing services use publicly trusted TLS certificates.
On this site: Operate TLS and certificates: configuration, renewal and verification (guide) · Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot (guide)
V12.3 General Service to Service Communication Security · 5 requirements
V12.3.1 Level 2
Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols.
V12.3.2 Level 2
Verify that TLS clients validate certificates received before communicating with a TLS server.
On this site: Operate TLS and certificates: configuration, renewal and verification (guide) · Improper TLS certificate validation (fix card)
V12.3.3 Level 2
Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications.
On this site: Authenticate workloads and authorize their service actions (guide)
V12.3.4 Level 2
Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates.
On this site: Operate TLS and certificates: configuration, renewal and verification (guide) · Improper TLS certificate validation (fix card)
V12.3.5 Level 3
Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as TLS client authentication, must be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security.
On this site: Authenticate workloads and authorize their service actions (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
Operate TLS and certificates: configuration, renewal and verification
Configure a modern TLS profile with hybrid post-quantum key exchange, automate renewal for certificate lifetimes that fall to 47 days, and verify every termination point with a fresh handshake.
Authenticate workloads and authorize their service actions
Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization.
RC4 keystream bias
Understand why fresh RC4 keys do not remove keystream bias and how repeated secret positions turn a small statistical effect into evidence.
64-bit block ciphers and the Sweet32 mechanism
Calculate the birthday effect for 64-bit blocks and derive the CBC relation that can turn a collision into a plaintext disclosure.
Lucky Thirteen and POODLE: two different oracles
Compare two CBC oracles by their signal, protocol rules, and attacker prerequisites instead of treating them as interchangeable padding bugs.
FREAK and Logjam: export-grade key exchange
Trace two export-grade downgrade paths and separate RSA factorization from finite-field Diffie–Hellman discrete logarithms.
DROWN: one RSA key across incompatible protocols
Map an RSA key across services to see how an SSLv2 oracle could compromise TLS traffic on a different endpoint.
Sweet32: the cost of a small block size
Read the 2016 Sweet32 demonstrations as evidence about traffic volume, repeated secrets, and session lifetime rather than treating a block-size threshold as an instant exploit.
References
- V12 Secure Communication (ASVS 5.0.0 source)
- OWASP - Transport Layer Security Cheat Sheet
- O-Saft - OWASP Project to validate TLS configuration
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.