Sensitive Data Exposure - Cybersecurity Academy

What is Sensitive Data Exposure?

Sensitive data exposure occurs when confidential information such as passwords, credit card numbers, health records, or API keys is inadvertently exposed, stored insecurely, or transmitted without proper protection. Unlike direct attacks, this vulnerability often stems from poor security practices or misconfigurations.

🧬 Common Types of Sensitive Data

Usernames and passwords (especially in plaintext)
Credit card numbers and financial details
Health records (PHI/PII)
Session tokens and authentication cookies
Internal IP addresses and configuration files
Source code, API secrets, and environment variables

🌐 Real-World Examples

Example 1: Exposed `.git` Directory

If the .git folder is publicly accessible, an attacker can download the source code and discover hardcoded secrets.

https://example.com/.git/config
https://example.com/.env

Example 2: Unencrypted Transmission

Sending login credentials over HTTP allows attackers to intercept data using packet sniffers.

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=admin&password=123456

This should always be transmitted over HTTPS with proper SSL/TLS.

Example 3: Verbose API Responses

Some APIs return sensitive internal fields in JSON responses unintentionally.

{
  "user": {
    "id": 101,
    "email": "user@example.com",
    "password_hash": "$2y$10$AbCdEf...",
    "auth_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

Response fields must be sanitized before being sent to the client.

🔎 How to Detect Sensitive Data Exposure

Inspect HTTP traffic using tools like Burp Suite or Wireshark
Search for exposed configuration files (.env, config.php, web.config)
Look for public S3 buckets or exposed storage services
Check for backup files (e.g., db.sql, backup.zip) via directory brute-forcing
Audit verbose error messages that reveal sensitive data

🛡️ Prevention & Remediation

Use strong encryption (AES-256, SHA-256) to store sensitive data
Never transmit credentials over HTTP—use HTTPS only
Store passwords using secure hash algorithms (e.g., bcrypt, Argon2)
Limit data exposure in API responses
Sanitize logs and error messages to avoid leaking secrets
Use security headers (e.g., Strict-Transport-Security)
Implement access controls on public storage (S3 buckets, Git repos)

🧰 Tools for Discovery & Testing

Burp Suite – Intercept traffic, test for leaks
dirsearch – Directory brute-forcing
httpx – Scan for HTTP misconfigurations
Nuclei – Vulnerability scanner for sensitive info
Shodan – Identify exposed infrastructure

💡 Pro Tips

Use Google Dorks like inurl:.env, filetype:sql password to identify exposed data
Set up alerts for new open storage buckets (e.g., AWS S3)
Automate checks with CI/CD security tools (e.g., GitLeaks, TruffleHog)
Perform regular audits of code, cloud storage, and logs