Sensitive data has to be identified before it can be protected, and caches, browsers and logs often keep it longer and more widely than intended.
- Classify sensitive data and document protection requirements for each level.
- Keep sensitive data out of URLs and shared caches, and send it only where it is needed.
- Limit what browsers store, with anti-caching headers, and clear it when the session ends.
- Apply retention rules and delete data that is no longer needed.
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-14.1.1.
V14.1 Data Protection Documentation · 2 requirements
V14.1.1 Level 2
Verify that all sensitive data created and processed by the application has been identified and classified into protection levels. This includes data that is only encoded and therefore easily decoded, such as Base64 strings or the plaintext payload inside a JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with.
On this site: Tokenization, pseudonymization and privacy transformations: choose deliberately (guide)
V14.1.2 Level 2
Verify that all sensitive data protection levels have a documented set of protection requirements. This must include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.
On this site: Data minimization and retention: collect less and prove that deletion works (guide)
V14.2 General Data Protection · 8 requirements
V14.2.1 Level 1
Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token.
On this site: Hard-coded secrets (fix card)
V14.2.2 Level 2
Verify that the application prevents sensitive data from being cached in server components, such as load balancers and application caches, or ensures that the data is securely purged after use.
On this site: Keep retrieval inside the user’s data boundary (guide) · Prevent shared-cache poisoning and private-response deception (guide)
V14.2.3 Level 2
Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control.
V14.2.4 Level 2
Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies, are implemented as defined in the documentation for the specific data's protection level.
On this site: Tokenization, pseudonymization and privacy transformations: choose deliberately (guide) · Case study: the LastPass breach (2022) (guide)
V14.2.5 Level 3
Verify that caching mechanisms are configured to only cache responses which have the expected content type for that resource and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when a non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks.
On this site: Prevent shared-cache poisoning and private-response deception (guide)
V14.2.6 Level 3
Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the complete data is required, it should be masked in the user interface unless the user specifically views it.
On this site: Data minimization and retention: collect less and prove that deletion works (guide) · Tokenization, pseudonymization and privacy transformations: choose deliberately (guide)
V14.2.7 Level 3
Verify that sensitive information is subject to data retention classification, ensuring that outdated or unnecessary data is deleted automatically, on a defined schedule, or as the situation requires.
On this site: Data minimization and retention: collect less and prove that deletion works (guide) · Defend agent memory and context against poisoning (OWASP ASI06) (guide)
V14.2.8 Level 3
Verify that sensitive information is removed from the metadata of user-submitted files unless storage is consented to by the user.
V14.3 Client-side Data Protection · 3 requirements
V14.3.1 Level 1
Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP response header field may be able to help with this but the client-side should also be able to clear up if the server connection is not available when the session is terminated.
V14.3.2 Level 2
Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers.
V14.3.3 Level 2
Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session tokens.
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
Data minimization and retention: collect less and prove that deletion works
Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit.
Prevent shared-cache poisoning and private-response deception
Define lookup and storage policy, trace cache/origin interpretation differences and verify both public reuse and private isolation.
Tokenization, pseudonymization and privacy transformations: choose deliberately
Choose between vault tokens, keyed pseudonyms, format-preserving encryption, aggregation and differential privacy by the joins, reversibility and leakage each allows, and test re-identification on the data you release.
GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
Map data, actors and processing purposes to the relevant GDPR, California or HIPAA requirements and preserve uncertainty about applicability.
Maintain an API inventory and prevent gateway bypass
Connect documented routes, deployed listeners and backend trust so retired or direct paths do not bypass the intended controls.
Operate edge rules without hiding application defects
Tune WAF and abuse controls against legitimate traffic, parser behavior and measurable business effects.
Practice
- Repair a real proxy and shared cache · Local project
References
- V14 Data Protection (ASVS 5.0.0 source)
- OWASP Secure Headers project
- OWASP Privacy Risks Project
- OWASP User Privacy Protection Cheat Sheet
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.