What Sensitive Data Exposure Really Means
Sensitive data exposure occurs when an application fails to adequately protect sensitive information such as credit card numbers, health records, session tokens, or passwords, either at rest in a database, in transit over the network, or in logs and backups. Unlike a single exploit technique, it is a category of failure: weak or missing encryption, hardcoded keys, plaintext storage, or transmitting secrets over unencrypted channels. OWASP later renamed this category to 'Cryptographic Failures' to emphasize that the root cause is almost always broken or absent cryptography rather than a specific attack vector.
Cricket analogy: It is like a team storing its unreleased match strategy and player fitness reports in an unlocked dressing room drawer instead of a safe, so anyone who wanders in during a Test match at Lord's can read the notes.
Data at Rest: Weak Storage and Broken Cryptography
Data at rest is exposed when applications store sensitive fields in plaintext, use reversible encoding like Base64 as if it were encryption, or rely on outdated algorithms such as MD5 or unsalted SHA-1 for password hashing. A properly designed system uses a memory-hard password hashing function like bcrypt, scrypt, or Argon2 with a unique salt per user, and encrypts other sensitive fields (card numbers, SSNs) with authenticated encryption such as AES-256-GCM, with keys managed by a dedicated key management service (KMS) rather than hardcoded in source code or environment files committed to version control.
Cricket analogy: Using MD5 for passwords is like a scorer recording every batter's PIN-protected locker code in plain ink on the public scoreboard instead of a coded ledger only the team manager can decrypt.
Data in Transit and Common Detection Points
Data in transit is exposed when applications allow HTTP instead of enforcing HTTPS, use outdated TLS versions (1.0/1.1), accept weak cipher suites, or fail to set HSTS headers, allowing man-in-the-middle attackers on shared networks (public Wi-Fi, compromised routers) to intercept credentials and session cookies. Detecting exposure requires reviewing TLS configuration with tools like SSL Labs' scanner, checking that cookies carry the Secure and HttpOnly flags, auditing logs and error messages for accidentally logged secrets, and scanning source repositories and cloud storage buckets for hardcoded credentials.
Cricket analogy: Running a login page over plain HTTP is like broadcasting a captain's tactical instructions over an open radio channel during a match instead of an encrypted team frequency, letting rivals eavesdrop.
// Bad: reversible encoding treated as encryption, plaintext storage
const stored = Buffer.from(creditCardNumber).toString('base64'); // NOT encryption
// Good: authenticated encryption with a KMS-managed key, salted password hashing
const crypto = require('crypto');
const bcrypt = require('bcrypt');
async function hashPassword(plainPassword) {
const saltRounds = 12;
return bcrypt.hash(plainPassword, saltRounds); // unique salt embedded per hash
}
function encryptField(plaintext, keyFromKms) {
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', keyFromKms, iv);
const encrypted = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);
const authTag = cipher.getAuthTag();
return { iv: iv.toString('hex'), authTag: authTag.toString('hex'), data: encrypted.toString('hex') };
}Never build your own encryption scheme or 'obfuscate' sensitive data with encoding like Base64, ROT13, or XOR. These are reversible without a key and provide zero real protection. Always use vetted libraries (libsodium, Node's crypto with AES-GCM, bcrypt/Argon2) and rotate keys through a managed KMS, never hardcoded in source or config files.
Preventing Exposure: Classification, Minimization, and Defense in Depth
Prevention starts with data classification: knowing exactly which fields are sensitive (PII, PCI, PHI) so protections can be applied consistently. From there, data minimization reduces risk by simply not collecting or retaining data that isn't needed, tokenizing card numbers via a payment processor instead of storing them, and truncating or masking sensitive values in logs and UI displays (showing only the last four digits of a card). Defense in depth combines encryption at rest, TLS everywhere with HSTS, strict access controls following least privilege, and automated secret-scanning in CI/CD pipelines to catch credentials before they are ever committed.
Cricket analogy: Tokenizing card data is like a stadium issuing a numbered token for a valuable bat left at the players' pavilion instead of writing the owner's home address on it, so the token is useless if stolen.
PCI-DSS explicitly forbids storing the CVV/CVC after authorization, and requires that stored primary account numbers (PANs) be rendered unreadable via strong cryptography, truncation, or tokenization. Treat this as a concrete, auditable example of data minimization plus cryptography working together.
- Sensitive data exposure (now called Cryptographic Failures in OWASP's naming) covers plaintext storage, weak hashing, and unencrypted transport of PII, credentials, and payment data.
- Use bcrypt, scrypt, or Argon2 with unique salts for passwords; never MD5, SHA-1, or reversible encoding.
- Encrypt sensitive fields at rest with authenticated encryption (AES-256-GCM) and manage keys via a KMS, never hardcoded.
- Enforce HTTPS everywhere with HSTS, disable TLS 1.0/1.1, and set Secure and HttpOnly flags on cookies.
- Practice data minimization and tokenization so sensitive values are never stored longer or more broadly than necessary.
- Mask or truncate sensitive fields in logs, error messages, and UI displays.
- Run automated secret scanning in CI/CD to catch hardcoded credentials before they reach production.
Practice what you learned
1. Why is Base64 encoding not an acceptable substitute for encryption of sensitive data?
2. Which password hashing approach is recommended over storing raw MD5 or SHA-1 hashes?
3. What is the primary purpose of tokenization for payment card data?
4. What does the HSTS header protect against?
5. According to PCI-DSS, what must happen to the CVV/CVC after a transaction is authorized?
Was this page helpful?
You May Also Like
Insecure Deserialization
Learn how deserializing untrusted data can lead to remote code execution, object injection, and denial of service, and how to safely handle serialized data.
SSRF Explained
Learn how Server-Side Request Forgery lets attackers trick a server into making unauthorized requests to internal systems, and how to prevent it.
Security Logging and Monitoring
Learn why insufficient logging and monitoring lets breaches go undetected for months, and how to build effective detection and response capability.