Data Protection, Secure Architecture, Logging, and WebRTC — ASVS 5.0 V14–V17

The first thirteen chapters of ASVS 5.0 address what happens during a request: encoding, validation, authentication, session management, authorization, cryptographic operations, and secure communication. Chapters V14 through V17 shift the frame. They address what happens after the application is running — how data persists and leaks, how the codebase ages, what the application records about itself, and what happens when the transport layer becomes real-time media. These four chapters form the operational layer of the standard.

V14 — Data Protection

Classification First

ASVS 5.0 does not prescribe which data is sensitive. It requires that your application does. Requirement 14.1.1 (Level 2) mandates that all sensitive data created and processed by the application has been identified and classified into protection levels. Critically, this includes encoded data — Base64 strings and JWT payloads are explicitly called out, since encoding is not encryption and plaintext inside a JWT is still plaintext.

Classification alone is not enough. Requirement 14.1.2 requires that each protection level has a documented set of controls covering encryption, integrity verification, retention, logging rules, database-level encryption, and applicable privacy-enhancing technologies. The intent is that classification drives control selection rather than existing as a paperwork exercise. Without those documented requirements, 14.2.4 — which verifies that the controls are actually implemented — cannot be meaningfully assessed.

This two-step structure (document the classification, document the controls, then implement them) is the template ASVS 5.0 uses across multiple chapters. It creates a verifiable chain from policy to implementation.

Sensitive Data in HTTP Responses

Three requirements address how sensitive data flows through the HTTP layer in ways that are easy to overlook:

• 14.2.1 (Level 1): Sensitive data must be transmitted in the HTTP request body or header fields. URLs and query strings are off limits. This is a Level 1 requirement because the attack surface is immediate — query parameters appear in server access logs, browser history, proxy logs, and Referer headers sent to third parties.
• 14.2.2 (Level 2): Server-side caches — load balancers, application caches — must not retain sensitive data, or must purge it securely after use. A shared application cache retaining a prior user's account details is a quiet data leakage channel.
• 14.3.2 (Level 2): Cache-Control: no-store (or equivalent anti-caching headers) must be set on responses containing sensitive data to prevent browser-level caching.

At Level 3, requirement 14.2.5 adds protection against Web Cache Deception attacks, requiring that caching mechanisms only cache responses with the expected content type and do not cache sensitive dynamic content. The mechanism is straightforward: a non-existent resource should return a 404 or 302, not silently serve a different valid file that might contain personalized data.

Browser Storage Security

Requirement 14.3.3 (Level 2) states a clear rule: browser storage — localStorage, sessionStorage, IndexedDB, cookies — must not contain sensitive data, with the single exception of session tokens.

The practical implications:

• Session tokens may live in cookies or sessionStorage, but nothing else sensitive should.
• Persistent user data like addresses, payment details, or health information must not be cached in localStorage.
• Anything cached for offline use warrants scrutiny against this requirement.

Requirement 14.3.1 (Level 1) adds the cleanup requirement: authenticated data must be cleared from client storage after session termination. The Clear-Site-Data HTTP response header is noted as a mechanism, but the requirement acknowledges that client-side cleanup logic is also necessary when the server connection is unavailable at logout time.

Data Minimization

Two Level 3 requirements reinforce data minimization principles that are often treated as compliance concerns rather than security controls:

• 14.2.6: The application must return only the minimum required sensitive data. Credit card numbers should show only the last four digits by default; the full number should be masked in the UI unless the user explicitly requests it.
• 14.2.7: Data retention classification must be enforced — outdated or unnecessary data must be deleted automatically on a defined schedule.
• 14.2.8: Sensitive metadata in user-submitted files (EXIF geolocation, document author fields, GPS coordinates embedded in photos) must be stripped unless the user consents to its storage.

V15 — Secure Coding and Architecture

The Dependency Problem

Chapter V15 opens with an honest acknowledgment: most applications ship more third-party code than first-party code. The requirements reflect this.

Requirement 15.1.1 (Level 1) requires documented, risk-based remediation timeframes for third-party components with known vulnerabilities. The timeframes are left to the organization — ASVS does not prescribe "patch within 30 days" — but they must exist and be written down before they can be enforced.

Requirement 15.1.2 (Level 2) requires an SBOM (Software Bill of Materials) covering all third-party libraries, verified against pre-defined, trusted, and continually maintained repositories. An SBOM that lists components but cannot tell you where they came from is of limited use. The "continually maintained" criterion matters: a dependency sourced from an abandoned fork or a mirrored registry that is no longer updated creates supply chain risk even if the current version appears clean.

Requirement 15.2.4 (Level 3) addresses dependency confusion attacks specifically — where a malicious package with the same name as an internal package is published to a public registry, and the build system resolves to the public version. Verifying that transitive dependencies also come from expected repositories closes this class of attack.

Requirement 15.1.4 (Level 3) requires that documentation explicitly flag "risky components" — third-party libraries that are poorly maintained, end-of-life, or have a history of significant vulnerabilities. Requirement 15.2.5 (Level 3) then requires that those flagged components be surrounded with additional architectural protections: sandboxing, encapsulation, containerization, or network-level isolation to limit blast radius if the component is compromised.

The two-step pattern is the same as V14: identify and document the risk, then demonstrate that the mitigating controls are in place.

Production Environment Hygiene

Requirement 15.2.3 (Level 2) targets a failure mode that is common in teams that move fast: test code, sample applications, and development stubs persisting in production environments. Debug endpoints, demonstration routes, development configuration files, and default application scaffolding all expand the attack surface without providing any production value. The requirement is to strip them. The verification is straightforward — it either exists in production or it does not.

Defensive Coding Practices

V15.3 covers language-level coding patterns that create security vulnerabilities:

• Mass assignment (15.3.3, Level 2): The application must limit which fields can be set by user input per controller and per action. This prevents an attacker from including unexpected fields in a request body and having the ORM or framework map them directly onto protected model attributes.
• Type juggling and type confusion (15.3.5, Level 2): Variables must be explicitly typed and comparisons must use strict equality. This is directly relevant to PHP (== vs ===) and JavaScript, where type coercion in comparisons has historically enabled authentication bypasses.
• Prototype pollution (15.3.6, Level 2): JavaScript code must use Set() or Map() rather than plain object literals where appropriate, to prevent prototype pollution — a class of attack where an attacker manipulates the prototype chain of all objects in the application.
• HTTP parameter pollution (15.3.7, Level 2): When a framework does not distinguish between query string parameters, body parameters, cookies, and header fields, duplicate parameters can produce unexpected behavior. The application must defend against this.

Architectural Controls: Least Privilege and Depth

V15 does not use the phrase "defense in depth" as a slogan — it operationalizes it. Risky operations and risky components must be isolated from the rest of the application. Authorization must be enforced at a trusted service layer. Production environments must contain only what is necessary. Backend calls must not follow redirects unless that is explicitly intended behavior (15.3.2, Level 2) — an SSRF mitigation that prevents a server-side request from being redirected to an internal resource.

V16 — Security Logging and Monitoring

What Must Be Logged

ASVS 5.0 is precise about the events that constitute the minimum required logging at Level 2:

• All authentication operations (16.3.1): Both successful and failed authentication attempts, with metadata about the authentication type and factors used.
• Failed authorization attempts (16.3.2): At Level 3, this extends to all authorization decisions and all accesses to sensitive data (without logging the sensitive data itself).
• Attempts to bypass security controls (16.3.3): Input validation failures, business logic violations, anti-automation triggers. These are high-signal events — legitimate users rarely trigger them at volume.
• Unexpected errors and security control failures (16.3.4): Backend TLS failures, certificate validation errors, circuit breaker trips. Infrastructure-level failures that have security implications must be captured in the security log, not silently absorbed.

The framing matters: ASVS treats the security log as distinct from error logs or performance logs. It is a purpose-built record of security-relevant events, not a general-purpose diagnostic stream.

Log Integrity

Requirement 16.4.1 (Level 2) requires that all logging components encode data to prevent log injection. An attacker who can inject a newline character into a logged value can create fake log entries, potentially covering their tracks or confusing automated analysis. The countermeasure is consistent output encoding of logged values — the same discipline applied to HTML output encoding applies here.

Requirement 16.4.2 (Level 2) requires that logs be protected from unauthorized access and modification. Logs that can be deleted or overwritten by an attacker who has compromised the application are forensically useless.

Requirement 16.4.3 (Level 2) closes the loop: logs must be transmitted to a logically separate system. The goal is simple — if the application is compromised, the attacker should not also have control over the logs needed to investigate that compromise. This does not prescribe a specific architecture (syslog to a separate host, a streaming pipeline, a managed log service), but the separation must be real.

What ASVS Does Not Require

ASVS 5.0 explicitly places alerting and correlation out of scope. The standard notes directly that "alerting and correlation (e.g., SIEM rules or monitoring infrastructure) are considered out of scope and are handled by operational and monitoring systems." ASVS verifies that the application produces high-quality, machine-readable, tamper-resistant logs. What the organization builds on top of those logs — SIEM rules, detection logic, alert routing, incident response playbooks — is outside the standard's scope.

This is a meaningful calibration point. An ASVS assessment that declares logging "compliant" cannot tell you whether your detection coverage is adequate. The standard establishes the raw material; the operational security program determines whether anything useful is done with it.

Log Content and Sensitive Data

Requirement 16.2.5 (Level 2) addresses the tension between logging enough to be useful and not turning log files into a secondary sensitive data store. Credentials and payment details must never appear in logs. Session tokens may only be logged in hashed or masked form. The protection level documented in V14 for each data classification directly informs what may and may not appear in logs.

The practical implication: a logging framework that captures full request/response bodies for debugging should not be active in production. Request bodies commonly contain credentials, payment card data, and PII — and a misconfigured logging configuration can silently ingest all of it.

Error Handling

V16.5 addresses secure failure modes:

• Error responses to clients must be generic — no stack traces, SQL queries, internal paths, secret keys, or tokens in production error messages (16.5.1, Level 2).
• Applications must continue operating when external resources fail, using patterns like circuit breakers or graceful degradation (16.5.2, Level 2).
• Validation errors must not cause transactions to be processed — the application must fail securely rather than fail open (16.5.3, Level 2).
• A last-resort error handler must catch all unhandled exceptions to prevent both log data loss and application process termination (16.5.4, Level 3).

V17 — WebRTC

Chapter V17 has the narrowest applicability in the standard — it is explicitly scoped to organizations that operate their own WebRTC infrastructure. Developers building applications on top of CPaaS vendor APIs (where the vendor operates the TURN servers, media servers, and signaling infrastructure) are explicitly excluded, because those vendors bear responsibility for the infrastructure security within their platforms.

If your application uses WebRTC through a third-party SDK and never operates its own media infrastructure, V17 does not apply. If you run your own TURN server, SFU, MCU, recording server, or signaling server — it does.

TURN Server Security

TURN servers relay media when peer-to-peer connectivity cannot be established. A misconfigured TURN server is an open relay — it can be abused to proxy traffic to internal network addresses, effectively providing an attacker with a pivot point into the private network.

Requirement 17.1.1 (Level 2) requires that the TURN service only allow relay access to IP addresses that are not reserved for special purposes — no RFC 1918 private addresses, no loopback, no broadcast, for both IPv4 and IPv6. This is the TURN analog of SSRF prevention: the relay must not be able to reach internal infrastructure.

Requirement 17.1.2 (Level 3) addresses resource exhaustion — a large number of simultaneous port allocation requests from legitimate users must not exhaust TURN server resources and deny service to others.

Media Server Security: DTLS-SRTP

Media servers handling real-time streams have a specific cryptographic challenge: they use DTLS (Datagram Transport Layer Security, the UDP-appropriate variant of TLS) rather than TLS, and the key exchange protocol (DTLS-SRTP, defined in RFC 5764) has its own security properties.

The core requirements:

• 17.2.1 (Level 2): DTLS certificate key material must be managed under the organization's cryptographic key management policy — the same policy that governs other long-lived keys.
• 17.2.2 (Level 2): Media servers must use only approved DTLS cipher suites and DTLS-SRTP protection profiles.
• 17.2.3 (Level 2): SRTP authentication must be verified at the media server. Unauthenticated RTP packets must be rejected — otherwise an attacker can inject audio or video into existing media streams, or trigger a denial of service by flooding the server with unauthenticated packets.
• 17.2.8 (Level 3): The DTLS certificate fingerprint must be validated against the SDP (Session Description Protocol) fingerprint attribute. If the check fails, the media stream must be terminated. This prevents man-in-the-middle attacks at the media layer — where an attacker intercepts the signaling and substitutes their own DTLS certificate.

Requirement 17.2.6 (Level 3) is operationally specific: media servers must not be susceptible to the DTLS ClientHello race condition vulnerability documented by Enable Security. This is an actual CVE class in widely deployed WebRTC stacks, and the requirement explicitly calls for either confirming the server is not publicly known to be vulnerable or performing the race condition test directly.

Signaling Server Security

WebRTC signaling — the coordination layer where peers exchange session descriptions and ICE candidates — is typically implemented over WebSocket or HTTP. The requirements for signaling servers are availability-focused:

• 17.3.1 (Level 2): Rate limiting at the signaling level to remain functional under flood attacks.
• 17.3.2 (Level 2): Input validation to handle malformed signaling messages (including integer overflow and buffer overflow scenarios) without crashing.

Both requirements reflect the reality that signaling disruption is a practical denial-of-service vector — if the signaling server goes down, no new calls can be established, even if the media infrastructure remains healthy.

The Operational Layer

Read together, V14 through V17 cover the concerns that become prominent after an application is deployed and running. Data leaks through unintended channels — cache headers, query strings, browser storage, log files, user-uploaded file metadata. Dependencies age and accumulate risk without active management. Security-relevant events go unrecorded, or are recorded in ways that make investigation impractical. Real-time communication infrastructure introduces cryptographic and availability threats that are distinct from the web application stack most security programs are built around.

The structural pattern ASVS 5.0 applies to all four chapters is consistent: document what you have (data classifications, SBOM, log inventory, cryptographic key policy), implement the controls those documents specify, and verify that the controls are in place. The documentation requirements are not bureaucratic overhead — they create the reference point against which the implementation can be tested.

For engineering teams planning an ASVS 5.0 compliance effort, these chapters reward attention to the Level 2 requirements first. The majority of the requirements in all four chapters are Level 2, and achieving Level 2 coverage here produces immediate operational security value: classified data inventories, maintained dependency lists with enforced patch timelines, structured security logs forwarded to a separate system, and properly configured WebRTC infrastructure where applicable. Level 3 builds on that foundation with more advanced controls — but the foundation itself is where the largest risk reduction sits.