RestingOwl owl logo RestingOwl
July 13, 2026 · 8 min read · By RestingOwl Security Desk

Data Protection in Web Apps:A Simple Developer Guide

Data ProtectionPrivacySecurityOWASPWeb Security
Quick answer: Data protection means keeping sensitive information safe through its whole life, wherever it lives. Start by knowing which data is sensitive, then collect as little as possible, encrypt it in transit and at rest, control how the browser caches and stores it, and delete it when you no longer need it. The less sensitive data you hold, the less you can lose.

Every app handles data, but not all data is equal. A blog title is public. A password, a card number, or a home address is not. Data protection is about treating sensitive data with the care it needs at every step. This guide keeps it simple and practical. It maps to chapter V14 of the OWASP standard, which you can explore in the ASVS Explorer.

What Counts as Sensitive Data?

Sensitive data is any information that could harm a person or your business if it leaked. It helps to sort your data into a few levels so you know how much protection each needs. This is called data classification, and it does not have to be complicated.

LevelExamplesHow to treat it
PublicBlog posts, product pages, marketing contentNo special protection needed.
InternalInternal docs, non sensitive settingsKeep behind login and access control.
SensitivePersonal data, emails, addresses, order historyEncrypt, limit access, and log who reads it.
Highly sensitivePasswords, card numbers, health data, keysStrong encryption, strict access, short retention, and extra care.

Why Is Collecting Less Data a Security Control?

The simplest way to protect data is to not hold it in the first place. This idea is called data minimization. If you do not collect a phone number you do not need, it cannot leak. If you delete old records you no longer use, they cannot appear in a future breach. Before you add a field to a form or a column to a table, ask whether you truly need it and how long you need to keep it. Holding less sensitive data lowers both your risk and your legal duties under privacy laws such as GDPR.

How Do You Protect Data at Each Stage?

Sensitive data moves through three stages, and each needs its own protection.

  • In transit. While data travels across the network, protect it with HTTPS and TLS so no one can read or change it. See our guide on HTTPS and TLS for the settings.
  • At rest. While data sits in a database, disk, or backup, encrypt it so a stolen copy is useless without the keys. Hash passwords with a strong algorithm rather than encrypting them, as covered in our password security guide.
  • In use and in the client. Be careful what you send to the browser and how it is stored there. Do not put sensitive data in localStorage where scripts can read it, and control caching so private pages are not saved on shared devices.

How Do You Control Caching of Private Data?

Browsers and proxies try to cache responses to make sites faster, but caching a private page can leave personal data on a shared computer or in an intermediate server. For pages and API responses that contain sensitive data, tell caches not to store them. A response header does this clearly.

Cache-Control: no-store

This tells browsers and shared caches not to keep a copy of the response. Use it on account pages, search results with personal data, and any API that returns sensitive fields.

Data Protection Checklist

Data Protection Checklist
  1. 1List your data and sort it into levels so you know what needs the most care.
  2. 2Collect only the sensitive data you truly need, and keep it only as long as you need it.
  3. 3Encrypt sensitive data in transit with HTTPS and at rest in your database and backups.
  4. 4Hash passwords with a strong algorithm instead of storing or encrypting them.
  5. 5Keep sensitive data out of browser storage that scripts can read.
  6. 6Set Cache-Control no-store on pages and responses with private data.
  7. 7Limit who and what can read sensitive data, and log access to it.
  8. 8Delete data you no longer need on a clear schedule.
Go deeper: Data protection is chapter V14 of the OWASP ASVS, and it overlaps with the A02 Cryptographic Failures risk in the OWASP Top 10. See how it connects to the wider standard in the ASVS Explorer.

References

  1. 1OWASP ASVS 5.0: V14 Data Protection
  2. 2OWASP Top 10: A02 Cryptographic Failures
  3. 3NIST Guide to Protecting the Confidentiality of PII

Q&A Section

Encryption is reversible: with the right key you can turn the data back into its original form, which is right for data you need to read again, like a stored address. Hashing is one way: you cannot turn the hash back into the original, which is right for passwords, where you only ever need to check a match, not read the value. Use encryption for data you must recover and strong hashing for passwords.
Not for sensitive data. Anything in localStorage can be read by JavaScript, so a single cross site scripting flaw can steal it. Keep tokens and personal data out of localStorage. Use secure, HttpOnly cookies for session identifiers, and keep sensitive data on the server where you control access.
Yes, they solve different problems. A private network stops outsiders from reaching the database, but encryption at rest protects the data if a disk, backup, or cloud snapshot is stolen or misconfigured. Defense in depth means using both, so that one failure does not expose everything.
Data you do not hold cannot be stolen, leaked, or misused. By collecting only what you need and deleting what you no longer use, you shrink the amount of sensitive data at risk in any future breach. It also reduces your duties under privacy laws, which expect you to justify and limit the personal data you keep.
Copied!