Flag{Hack}
Identicon for Demo
Demo
Courses
Labs
Courses

Information Disclosure

Information Disclosure is a class of vulnerabilities where a system unintentionally exposes sensitive, internal, or security-relevant information to unauthorized users.

Unlike direct exploits (such as SQL Injection), information disclosure is often passive, silent, and extremely powerful when chained with other vulnerabilities.

Why It Matters

  • Lowers the cost of attack
  • Reduces guesswork
  • Enables precision exploitation
  • Often requires no authentication
  • Is frequently overlooked by developers

In real-world attacks, information disclosure is almost always the first successful step.

Disclosure Taxonomy

Information disclosure appears in different technical layers. Classifying leaks helps attackers (and defenders) reason about impact and chaining potential.

  • Content Disclosure— Sensitive data rendered directly into the UI (banners, debug panels, admin hints).
  • Source Disclosure— Information hidden in HTML, comments, hidden inputs, JavaScript bundles, or embedded config.
  • Transport Disclosure— Data leaked via HTTP headers, cookies, or caching behavior.
  • Artifact Disclosure— Exposed deployment leftovers such as .env, /.git/, backups, robots.txt, or source maps.
  • Behavioral Disclosure— Errors, stack traces, timing differences, or response variations that reveal internal logic.
  • API Disclosure— Excessive data exposure in JSON responses (roles, flags, hashes, internal metadata).
Strong attackers don't just "look for flags" — they identify which disclosure layer they're dealing with.

Information Disclosure in the Attack Lifecycle

Reconnaissance (Passive & Active)

  • Banner grabbing
  • Metadata analysis
  • Public file discovery
  • Error observation

Exploitation Preparation

  • Identifying software versions
  • Learning backend architecture
  • Discovering hidden endpoints
  • Mapping authentication logic

Without disclosure, attackers guess. With disclosure, attackers calculate.

Attacker Tooling for Discovery

  • Network scanners with version detection
  • Web vulnerability scanners
  • Internet-wide search engines
  • Intercepting proxies
  • Custom recon scripts

Advanced attackers rely heavily on custom tooling because disclosure patterns vary across applications.

Page Content

The simplest leaks are visible because they are rendered into the UI: banners, 'status' widgets, footers, debug panels, welcome messages, and admin hints. Attackers skim the page like a log file, not like a user interface.

  • Scan for keywords: token, secret, debug, admin, internal.
  • Look at 'small text' zones: footers, tooltips, hidden accordion sections, 'About' panels.
  • Watch for content that appears only after actions (clicking, opening modals, form validation).
Example of a visible disclosure: Welcome back, admin. Temporary access token: =dw93j-flaghack-temp-token-abc123

View Page Source for Non-Rendered Data

Attackers always open View Page Source because developers often leave information in HTML that is not visibly rendered: comments, hidden inputs, inactive UI blocks, or 'temporary' notes.

  • Right click → View Page Source(or DevTools → Elements).
  • Search the HTML for: FLAG, TODO, remove, staging, internal.
  • Pay attention to: <!-- comments -->, data-* attributes, <input type="hidden">.
<!-- TODO: remove before production --> <!-- support bypass token: FLAG{SOURCE_COMMENT_DISCLOSURE} --> <input type="hidden" name="debug_session" value="FLAG{HIDDEN_FIELD_DISCLOSURE}" />

Inspect JavaScript and Frontend Configuration

Modern apps ship a lot of configuration to the client. Attackers look for config objects, feature flags, endpoints, and keys that were never meant to be public.

  • Open DevTools → Sources and search across files for key, token, config, admin.
  • Check for globals: window.__CONFIG__, __NEXT_DATA__, env, settings.
  • Look for 'temporary' logic like: if (isInternalUser), enableDebug, bypassAuth.
<script> window.__APP_CONFIG__ = { apiBaseUrl: "/api", supportKey: "FLAG{JS_CONFIG_DISCLOSURE}", adminExportEndpoint: "/api/admin/exportUsers" }; </script>

Encoding

Developers sometimes 'hide' values by encoding them. Attackers treat this as a hint, not protection. Base64 is especially common.

  • Base64 often looks like random text and may end with = or ==.
  • Attackers decode immediately to check if it's a token, credentials, or internal URL.
Encoded: RkxBR3tCQVNFNjRfRElTQ0xPU1VSRX0= Decoded: FLAG{BASE64_DISCLOSURE}

HTTP Headers (Information That Never Appears in HTML)

Many disclosures happen in HTTP headers: server software, versions, internal routing, debug flags, and accidental secret headers. Attackers always inspect headers because they're easy to forget and often added by proxies/middleware.

  • DevTools → Network→ click the main document request → Headers.
  • Also inspect API requests in the same way (fetch/XHR).
  • Watch for: Server, X-Powered-By, X-Debug-*, X-Env, X-Internal-*.
Example response headers: Server: nginx/1.18.0 X-Powered-By: Express X-Internal-Host: api.internal.local X-Debug-Token: FLAG{HEADER_DISCLOSURE}

Forgotten Files

Attackers probe for files that commonly exist in real deployments: robots.txt, backups, configs, and accidentally exposed repository artifacts. These files often disclose endpoints, credentials, or the entire source tree.

  • Common first checks: /robots.txt, /sitemap.xml, /.well-known/
  • High-risk leftovers: /.env, /.git/, /backup.zip, /site-backup.tar.gz, /config.yml
  • Attackers also try predictable names: backup-old.zip, app.bak, db.dump, .DS_Store
Example robots.txt disclosure: User-agent: * Disallow: /admin Disallow: /internal/status Disallow: /backup/ This doesn't "protect" those paths — it advertises them.

Source Maps: Accidentally Published

Source maps (.map) are meant for debugging, but in production they can expose original source code, internal comments, endpoints, and secret constants. Attackers look for them immediately.

  • DevTools → Network→ search for .map files.
  • In Sources, use global search for TODO, internal, admin, FLAG.
Example disclosure from a source map: const INTERNAL_ADMIN_ENDPOINT = "/api/admin/exportUsers"; const SUPPORT_TOKEN = "FLAG{SOURCEMAP_DISCLOSURE}";

Error Pages and Stack Traces (Path + Tech + Structure)

When apps leak detailed errors, attackers extract technology fingerprints and internal structure: file paths, line numbers, framework versions, and database hints. Even when no secret is shown, the metadata is valuable.

  • Attackers note: language, framework, file system layout, module names, table names.
  • They compare errors across endpoints to map backend architecture.
Example stack trace leak: TypeError: Cannot read properties of undefined at getUser (/usr/src/app/services/user.service.ts:88) at route (/usr/src/app/routes/profile.ts:41) What this reveals: - Node/TypeScript stack - Internal file structure - Exact filenames and line numbers

API Responses: Excessive Data Exposure

Attackers treat APIs as a data mine. They inspect JSON for fields that should never reach the client: roles, internal flags, hashes, or debug fields. This is one of the most common real-world disclosure patterns.

  • DevTools → Network→ inspect fetch/XHR responses.
  • Compare what the UI needs vs what the API returns.
  • Watch for: role, isAdmin, is_internal, password_hash, debug metadata.
Example excessive exposure: { "id": 42, "email": "user@example.com", "role": "admin", "is_internal": true, "password_hash": "$2y$10$...", }

Chaining Information Disclosure into Exploitation

  1. Version disclosure reveals outdated framework
  2. Stack trace exposes file paths
  3. Configuration file leaks credentials
  4. Admin endpoints are discovered
  5. Authentication is bypassed
  6. Remote code execution is achieved

Information disclosure is rarely the final vulnerability — it is the enabler.

Prevention

Production Hardening

  • Disable debug modes
  • Sanitize error messages
  • Use generic authentication errors
  • Strip identifying headers

Secrets Management

  • Never store secrets in the web root
  • Rotate credentials immediately after leaks
  • Use secure environment variable handling

Secure Defaults & Testing

  • Disable directory listing
  • Remove unused endpoints
  • Perform adversarial testing

Key Takeaways

  • Information disclosure is quiet but extremely dangerous
  • It turns blind attacks into precision strikes
  • Most real-world compromises start here

Quiz

You find `X-Internal-Host: api.internal.local` in response headers. Why is this valuable to an attacker?

It reveals internal network naming and architecture
It proves TLS is misconfigured
It automatically grants admin access
It prevents caching attacks

A frontend bundle contains `supportKey: "FLAG{...}"`. What is the root security failure?

Sensitive secret embedded in client-shipped configuration
SQL injection in the API
CSRF token reuse
Broken TLS certificate chain

You encounter `RkxBR3tCQVNFNjRfRElTQ0xPU1VSRX0=` in page source. What should you do first?

Attempt Base64 decoding
Assume it is properly encrypted
Hash it with bcrypt
Ignore it because it ends with =

Why are source maps dangerous when exposed in production?

They can reveal original source code, comments, endpoints, and constants
They automatically disable authentication
They expose database backups directly
They cause SQL injection

An API response includes `password_hash` and `is_internal` even though the UI does not use them. What is this vulnerability called?

Excessive data exposure
Clickjacking
Open redirect
DNS rebinding

Which response indicates proper remediation after a public token leak?

Immediately rotating and invalidating the leaked credentials
Hiding the token with Base64
Removing the token from the UI only
Adding more frontend validation