> For the complete documentation index, see [llms.txt](https://notes.dollarboysushil.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.dollarboysushil.com/web-application-pentest/information-disclosure.md).

# Information Disclosure

## Information Disclosure - Overview

### 1. What it is

* App leaks info it shouldn't, to users or attackers - aka "information leakage"
* What gets leaked:
  * Other users' data (usernames, emails, financial info)
  * Business/commercial data
  * Technical infra details (server, framework, versions)
* Often surfaces while testing something else entirely - keep an eye out even off-task

### 2. Why it matters even when it "looks minor"

* Direct leak (credit card numbers, PII) → obviously severe on its own
* Technical leak (framework version, directory structure) → looks harmless, but:
  * Confirms attack surface for something else
  * Old/vulnerable framework version + public exploit = easy win
  * Can be the missing piece for a bigger, chained attack
* **Severity test:** does the leaked info let you *do* something harmful? If not exploitable, don't over-flag it - common sense over box-ticking

### 3. Root causes (pick one, this is basically always why)

* **Leftover internal content** - dev comments, debug notes not stripped before prod
* **Insecure configuration** - debug/diagnostic features left on, verbose default errors, unneeded features enabled
* **Flawed app logic** - different responses for different internal states → lets you enumerate data (ties directly into username enumeration)

### 4. How to test - techniques

* **Fuzz parameters** - throw unexpected types/fuzz strings, watch for:
  * Status code differences
  * Response length differences
  * Timing differences
  * Use Burp Intruder + grep-match/extract for `error`, `SQL`, `invalid`, etc.
* **Burp Scanner** - auto-flags leaked keys, emails, card numbers, backup files, directory listings
* **Burp engagement tools** (right-click → Engagement tools):
  * Search - find/negative-search any keyword
  * Find comments - pulls dev comments out automatically
  * Discover content - finds unlinked dirs/files
* **Force informative errors** - feed invalid input on purpose, see what the stack trace/debug response gives up

### 5. Common places to check

* [ ] `/robots.txt` and `/sitemap.xml` - lists paths crawlers are told to skip (often the interesting ones)
* [ ] Directory listings - enabled dirs with no index page expose every file inside
* [ ] HTML source / dev comments - view-source, look for leftover notes hinting at hidden paths or logic
* [ ] Error messages - verbose errors reveal expected input types, DB/template engine names, version numbers
* [ ] Debug endpoints/data - session vars, backend hostnames, credentials, encryption keys, file paths
* [ ] User account/profile pages - check if a `user` parameter can be swapped to pull another user's data without full account access
* [ ] Backup files - `.bak`, `~`, `.old`, `.swp` on known source file names → can return raw source instead of executed output
* [ ] Insecure config - HTTP `TRACE` method enabled can echo back internal headers (e.g. reverse-proxy auth headers)
* [ ] `.git` directory exposed - download it, read commit history/diffs for hardcoded secrets

### 6. Prevention (dev-side, good to know for reports/writeups)

* Everyone on the team should know what counts as "sensitive" - non-obvious stuff leaks too
* Strip dev comments before deploy (automate it in CI/QA)
* Use generic error messages - don't hand attackers free clues
* Disable debug/diagnostic features in production, every time
* Understand the config + security implications of every third-party tool in use, turn off what you don't need