OWASP Sensitive Data Exposure

Sensitive Data Exposure falls under A02 Cryptographic Failures in the OWASP Top 10. It occurs when an application fails to adequately protect sensitive information — such as passwords, credit card numbers, health records, or personal identifiers — either in storage or while transmitting it across a network.

The Unlocked Filing Cabinet Analogy

A doctor stores patient records in a filing cabinet. The cabinet sits in the waiting room, unlocked, visible to every visitor. Nobody stole the key — the records were simply never secured to begin with. Sensitive data exposure works the same way: the attacker does not need a sophisticated technique. The data is just sitting there unprotected.

What Counts as Sensitive Data

  Passwords and password hashes
  Credit card and bank account numbers
  Social Security / national ID numbers
  Health and medical records
  Personally Identifiable Information (PII) — names, addresses, dates of birth
  Private API keys and tokens
  Encryption keys and certificates
  Legal documents and contracts

How Sensitive Data Gets Exposed

Transmitted Over HTTP Instead of HTTPS

Data sent over plain HTTP travels in clear text. Anyone on the same Wi-Fi network — at a coffee shop, airport, or hotel — can read it with freely available tools.

  HTTP request captured on shared Wi-Fi:
  POST /login HTTP/1.1
  Host: bank.example.com

  username=alice&password=SuperSecret99

  Attacker sees the password in plain text.

Passwords Stored in Plain Text

If the database is ever breached, plain-text passwords give the attacker instant access to every account — on that site and on every other site where the user reused the password.

Weak Password Hashing

MD5 and SHA-1 are fast hashing algorithms designed for data integrity, not password storage. Attackers precompute billions of MD5 hashes and reverse a stolen hash to its original password in seconds.

  Stolen hash:  5f4dcc3b5aa765d61d8327deb882cf99
  Lookup table: 5f4dcc3b... = "password"
  Cracked in:   Milliseconds

Sensitive Data Cached or Logged Unnecessarily

Credit card numbers written to log files, session tokens stored in browser caches, or full request bodies saved in proxy logs — all create copies of sensitive data in places with weaker protection than the main database.

Backup Files Not Encrypted

A database backup stored on a cloud server without encryption is just as dangerous as the live database without protection. Attackers target backup files specifically because they are often less carefully monitored.

Real-World Data Exposure Pattern

  E-commerce site stores 2 million customer credit card numbers
         |
         | Stored in plain text in the database
         v
  Database server misconfigured — accessible from the internet
         |
         v
  Attacker finds open port, connects to database
         |
         v
  Downloads entire credit card table in 10 minutes
         |
         v
  2 million cards sold on dark web marketplaces

How to Prevent Sensitive Data Exposure

1. Classify Your Data

Know what data your application handles. Identify which fields are sensitive and apply the strongest protections to those fields. Not every piece of data needs the same treatment.

2. Enforce HTTPS Everywhere

Redirect all HTTP traffic to HTTPS. Use the Strict-Transport-Security header to tell browsers to always use HTTPS for your domain. Obtain a free certificate from Let's Encrypt.

3. Hash Passwords with a Strong Algorithm

Use bcrypt, scrypt, or Argon2 for password storage. These algorithms are deliberately slow and include a random salt, making precomputed lookup attacks impractical.

  MD5 hash (weak, never use for passwords):
  5f4dcc3b5aa765d61d8327deb882cf99   -- Crackable in milliseconds

  bcrypt hash (strong):
  $2b$12$EixZaYVK1fsbw1Zfbx3OXePaWxn96p36...  -- Infeasible to crack

4. Do Not Store Data You Do Not Need

Never store full credit card numbers — use a payment gateway that tokenizes card data so your system only stores a reference token. Delete personal data when it is no longer needed.

5. Encrypt Sensitive Data at Rest

Use database-level or field-level encryption for highly sensitive columns. Encrypt backup files before uploading them to cloud storage.

6. Disable Sensitive Data in Logs and Caches

Configure your logging framework to redact or exclude passwords, tokens, and card numbers. Set no-store and no-cache headers on responses that contain sensitive data.

Quick Prevention Checklist

  [✓] HTTPS enforced on every page and API
  [✓] Passwords hashed with bcrypt, scrypt, or Argon2
  [✓] No plain-text storage of sensitive fields
  [✓] Sensitive data excluded from logs and caches
  [✓] Backups encrypted before storage
  [✓] Collect and retain only the data you actually need

Key Takeaway

Sensitive data exposure is often not about sophisticated hacking — it is about data that was never protected in the first place. Encrypt data in transit with HTTPS, hash passwords with modern algorithms, and store only what you truly need.