|
| 1 | +# OWASP ASVS 5.0 Level 2 — self-assessment |
| 2 | + |
| 3 | +**Standard:** OWASP Application Security Verification Standard, version |
| 4 | +5.0.0, chapter V12 (Secure Communication). |
| 5 | +**Level:** 2 (typical baseline; consumers needing L3 must layer |
| 6 | +additional controls). |
| 7 | +**Scope:** Server-side TLS termination via `Builder.https(...)`. |
| 8 | +Outbound / service-to-service controls (V12.3) are N/A — the library |
| 9 | +makes no outbound TLS connections on the consumer's behalf. |
| 10 | + |
| 11 | +**Wording rules.** This document is a self-assessment; it does NOT |
| 12 | +claim certification or compliance. The README badge says "ASVS 5.0 |
| 13 | +Level 2" only — never "Certified", never "Compliant". OWASP does not |
| 14 | +issue conformance certifications. |
| 15 | + |
| 16 | +**Re-affirmation rule.** Any change to TLS-related code (see |
| 17 | +`.github/scripts/asvs-gate.sh` for the exact predicate) MUST append a |
| 18 | +dated entry to the [Audit log](#audit-log) in the same PR. CI |
| 19 | +enforces this. The contributor writes the line — automated bumps are |
| 20 | +not accepted. |
| 21 | + |
| 22 | +**Status legend.** |
| 23 | + |
| 24 | +- ✅ Implemented — the library satisfies this control end-to-end |
| 25 | +- 🤝 Delegated — consumer must satisfy; see Evidence for guidance |
| 26 | +- ⛔ N/A — out of scope for a server-side TLS termination library |
| 27 | +- 📋 Future — accepted as a gap; tracked for a follow-up release |
| 28 | + |
| 29 | +## Controls |
| 30 | + |
| 31 | +| ID | Control (verbatim, ASVS 5.0) | Level | Status | Evidence | |
| 32 | +|---|---|---|---|---| |
| 33 | +| 12.1.1 | "Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3." | L1 | ✅ Implemented | `TlsHttpsConfigurator` pins `setProtocols({"TLSv1.3","TLSv1.2"})`; verified end-to-end by `OpenApiServerHttpsIT#negotiatesTls13`. | |
| 34 | +| 12.1.2 | "Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred." | L2 | 📋 Future | We rely on JDK 25 defaults (which exclude RC4, 3DES, EXPORT, NULL, anonymous suites by default). A curated allowlist with explicit preference order is tracked as a follow-up. | |
| 35 | +| 12.1.3 | "Verify that the application validates that mTLS client certificates are trusted before using the certificate identity." | L2 | ⛔ N/A | mTLS is not supported in v1. `TlsHttpsConfigurator` explicitly sets `setNeedClientAuth(false)` and `setWantClientAuth(false)`. If mTLS lands later, this row flips to Implemented + new evidence. | |
| 36 | +| 12.1.4 | "Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled." | L3 | 📋 Future | Out of scope for L2 baseline. Documented so L3-targeting consumers know the gap. | |
| 37 | +| 12.1.5 | "Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata." | L3 | 📋 Future | Out of scope for L2 baseline. JDK 25 has no stable ECH API. | |
| 38 | +| 12.2.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 communications." | L1 | ✅ Implemented | When `.https(...)` is configured, the server binds `HttpsServer` only; no plaintext fallback listener is created. Mixed-mode (HTTP + HTTPS) is a documented non-goal — operators run two `OpenApiServer` instances if they need both. | |
| 39 | +| 12.2.2 | "Verify that external facing services use publicly trusted TLS certificates." | L1 | 🤝 Delegated | The library accepts whatever cert chain the consumer supplies. For production deployments, consumers MUST point `.https(certChain, privateKey)` at a chain signed by a publicly-trusted CA. See satisfaction guidance below. | |
| 40 | +| 12.3.1 – 12.3.5 | (Service-to-service / outbound) | L2 | ⛔ N/A | The library does not initiate outbound TLS on the consumer's behalf. Consumers' outbound HTTP clients are their own responsibility. | |
| 41 | + |
| 42 | +### Delegated control: satisfaction guidance |
| 43 | + |
| 44 | +**12.2.2.** Operators should point `.https(certChain, privateKey)` at |
| 45 | +a chain issued by a publicly trusted CA. The recommended workflow is |
| 46 | +certbot / Let's Encrypt with the PEM files mounted from a secret |
| 47 | +manager (see README §HTTPS for the full deployment pattern). The |
| 48 | +library performs no chain validation on its own certificate — the |
| 49 | +server merely presents the chain — so it is on the operator to ensure |
| 50 | +publicly-trusted issuance. |
| 51 | + |
| 52 | +## Audit log |
| 53 | + |
| 54 | +- **2026-05-21** — Initial ASVS 5.0 Level 2 mapping for V12 controls. All listed controls accepted as Implemented / Delegated / N/A / Future as tabulated above. |
0 commit comments