Sensitive Data Exposure and Insecure Cryptographic Storage

This Vulnerability Explain post covers Sensitive Data Exposure, also framed in OWASP as Cryptographic Failures. It is about what happens when applications fail to protect sensitive information – passwords, payment data, personal records – with strong encryption in transit and at rest. Let’s break it down.

What is Sensitive Data Exposure?

Sensitive Data Exposure happens when an application does not adequately protect sensitive data, through missing encryption, weak algorithms, poor key management, or simply storing and transmitting secrets in a recoverable form.

Examples include passwords stored as plain text or weak hashes, traffic served over HTTP instead of HTTPS, credit card numbers logged in clear text, or backups left unencrypted. The data is there for the taking if an attacker reaches it.

How does Sensitive Data Exposure work?

Sensitive data ends up exposed through several common failures:

• Weak or Missing Encryption in Transit
  • Data travels over plaintext HTTP or with outdated TLS, allowing interception.
• Weak Storage
  • Sensitive data is stored unencrypted, or passwords use fast or unsalted hashes.
• Poor Key Management
  • Keys are hardcoded, reused, or stored alongside the data they protect.
• Incidental Leakage
  • Secrets appear in logs, error messages, URLs, or analytics.
• Compromise
  • An attacker who reaches the data – via a breach, interception, or leak – can read it directly.

The goal is that even if an attacker gets the data, it is useless to them. Strong, well-managed cryptography is what makes that true.

How sensitive data exposure works: weak or missing encryption leaks data in transit and at rest.

Tools and Techniques for Sensitive Data Exposure Testing

Testing combines transport analysis, storage review, and checks for leaked secrets.

Manual Testing Methodologies

• Transport Inspection – Verify HTTPS everywhere, strong TLS configuration, and HSTS.
• Storage Review – Check how passwords and sensitive fields are stored and hashed.
• Leak Hunting – Look for secrets in logs, URLs, source, error pages, and client-side code.
• Algorithm Audit – Identify weak ciphers, MD5/SHA1 for passwords, or ECB mode encryption.

Automated Scanning Tools

• testssl.sh – Thoroughly tests TLS configuration and weaknesses.
• TruffleHog – Finds secrets and keys leaked in code and history.
• Gitleaks – Detects hardcoded secrets in repositories.
• SSL Labs – Grades the TLS configuration of a site.

Sensitive Data Exposure Protection Mechanisms

Best Practices for Secure Coding

• Encrypt in Transit and at Rest
  • Description: Use TLS for all traffic and strong encryption for stored sensitive data.
  • Benefits: Intercepted or stolen data stays unreadable.
  • Implementation Tip: Enforce HTTPS with HSTS and use modern AES-based encryption.
• Hash Passwords Properly
  • Description: Store passwords with a slow, salted algorithm.
  • Benefits: Cracking stolen hashes becomes impractical.
  • Implementation Tip: Use bcrypt, scrypt, or Argon2 – never MD5, SHA1, or unsalted hashes.
• Manage Keys and Minimize Data
  • Description: Store keys separately in a vault and collect only the data you need.
  • Benefits: Limits exposure and blast radius.
  • Implementation Tip: Rotate keys and never hardcode them.

Best Practices for Organizations

• Data Classification
  • Identify and classify sensitive data across the system.
  • Apply controls proportional to sensitivity.
• Secret Management
  • Use a centralized secrets manager.
  • Keep secrets out of code, logs, and config files.
• Compliance and Testing
  • Align with standards like PCI DSS and GDPR where relevant.
  • Regularly audit encryption and secret handling.

Top Sensitive Data Exposure payloads used by Security Researchers

As a security researcher, knowing the most common payloads helps you detect and prevent these attacks. Use this knowledge ethically and only on systems you are authorized to test. Some sample payloads are shown below.

// Weak password hashing to avoid
MD5(password)
SHA1(password)
unsalted SHA-256(password)

// Strong password hashing to use
Argon2id(password, salt, memory, iterations)
bcrypt(password, cost=12)

// Insecure transport indicators
http:// (no TLS)
TLS 1.0 / 1.1, RC4, ECB mode

// Secret leaking in a URL (avoid)
GET /reset?token=secret&apikey=AKIA... HTTP/1.1

Real-World Example: Plaintext Passwords After a Breach

A community site stored user passwords using unsalted MD5, a fast and long-broken hash, and served some pages over plain HTTP.

When the database leaked, attackers cracked the vast majority of the MD5 hashes within hours using common wordlists, then reused those passwords against the victims’ other accounts. The HTTP pages had also exposed session cookies to network attackers.

The fix migrated to Argon2 password hashing, enforced HTTPS with HSTS, and moved keys into a vault. Sensitive Data Exposure is about assuming a breach will happen and making sure the data is worthless when it does.

Vulnerable and secure code of Sensitive Data Exposure

The following example shows the contrast between vulnerable and secure code for Sensitive Data Exposure. It helps you see how the flaw creeps into real code and the changes that shut it down.

🥺 Vulnerable Code:

# Vulnerable: fast, unsalted hash and plaintext storage habits
import hashlib

def store_password(password):
    # MD5 is fast and broken - trivially cracked from a leak
    return hashlib.md5(password.encode()).hexdigest()

# Sensitive data also logged in clear text
logging.info(f"User card number: {card_number}")

• MD5 is unsalted and fast, so leaked hashes are cracked almost instantly.
• Logging raw card numbers leaks sensitive data into log files.

😎 Secure Code:

# Secure: slow salted hashing and no sensitive data in logs
from argon2 import PasswordHasher

ph = PasswordHasher()  # Argon2id with sensible defaults

def store_password(password):
    return ph.hash(password)   # unique salt handled automatically

def verify_password(stored, password):
    return ph.verify(stored, password)

# Never log secrets; log a non-sensitive reference instead
logging.info(f"Payment processed for order {order_id}")

• Argon2 is slow and salted, making large-scale cracking impractical.
• Sensitive values are kept out of logs entirely.

Conclusion

Sensitive Data Exposure is best fought by assuming attackers will eventually reach the data and making it useless to them. Encrypt everything in transit and at rest, hash passwords with Argon2, bcrypt, or scrypt, manage keys in a vault, minimize what you collect, and keep secrets out of logs and URLs. Strong, well-managed cryptography turns a breach from a catastrophe into a non-event.