Information Disclosure

The largest bucket in the corpus, spanning very different sub-classes:

• outdated-software CVE markers (Jira CVE-2020-14179, ColdFusion, Confluence, GitLab) - already covered by Nuclei
• public source / config leaks (.env, .git/config, phpinfo, /debug, dump.sql, backup.tar, .DS_Store)
• client-side secrets in JS bundles, sourcemaps, and HTML comments (Google/Stripe/Mapbox/Sentry/Firebase keys, JWT, AWS access-key fragments)
• public cloud storage misconfiguration (open S3 buckets, GCS, Azure Blob)
• GraphQL introspection enabled in production
• PII docs / PDFs / CSVs publicly served (DoD pattern of leaked rosters, customer lists)
• lookup oracles - submitting email/phone to a public form returns whether it exists or its associated full name
• error pages leaking stack traces, SQL queries, file paths, internal hostnames
• verbose response headers (X-Powered-By, version banners, Server: detailed)
• missing access controls returning data the user shouldn't see (which overlaps with IDOR but is reported as info-disclosure when no object id is involved). Most of this is detectable from the outside without authentication.

• Outdated Atlassian Jira / Confluence instances
• WordPress sites with default REST endpoints exposed
• Spring Boot services with /actuator on the public route
• PHP applications shipping phpinfo() pages from dev
• Open S3 / GCS / Azure Blob buckets named after the brand
• GraphQL APIs with introspection on
• JS bundles and sourcemaps shipping secrets
• Public PDFs/CSVs containing PII (DoD repeat pattern)
• Customer lookup / chat widgets accepting email and returning name
• Old admin debug endpoints (/.well-known/, /debug, /trace, /env)

• Probe known disclosure-CVE paths against detected products (Jira, Confluence, ColdFusion)
• Fetch /.env, /.env.production, /.env.local, /.git/config, /.git/HEAD, /.svn/entries
• Fetch /phpinfo.php, /info.php, /test.php, /server-status, /server-info, /actuator, /actuator/env, /actuator/heapdump
• Fetch /sitemap.xml, /robots.txt and look for disallowed admin paths leaking via Disallow
• Find .map files for every .js bundle and parse for secrets / internal URLs
• Submit email/phone to public forms and observe response differential (200 vs 404 vs 403)
• Enumerate users via /wp-json/wp/v2/users, /api/v1/users?id=N, /search?q=*
• Fetch GraphQL endpoint with {__schema{types{name}}} to test introspection
• Trigger error states (long input, malformed JSON, special chars) and parse stack traces
• Probe S3 / GCS / Azure with the company brand name and bucket-name conventions

• /.env
• /.env.local
• /.env.production
• /.git/config
• /.git/HEAD
• /.git/logs/HEAD
• /.svn/entries
• /.DS_Store
• /phpinfo.php
• /info.php

Because this category spans so many unrelated root causes, real coverage means running through each sub-class independently rather than looking for one shared signal. Version-fingerprint CVE matching handles the outdated-software cases directly (Jira's CVE-2020-14179, Confluence advisories, ColdFusion's CFIDE exposure, and similar). A broad sensitive-file probe covers the rest of the exposed-file family: beyond the basics (.env, .git/config, backup archives), it's worth extending the wordlist to Spring Boot's /actuator/* family (heapdump, env, trace), /server-status, /server-info, /CFIDE/administrator/, /wp-json/wp/v2/users, /.well-known/openid-configuration, /swagger-ui.html, /openapi.json, /composer.json, and /package.json. Every match needs real content validation rather than trusting a 200 status alone, since plenty of applications return a 200 with their SPA shell for any path at all: an /actuator/env hit should contain a propertySources array, a .env hit should contain KEY=VALUE pairs, a phpinfo hit should contain the literal string phpinfo().

Beyond file exposure, several other sub-classes need their own dedicated checks. For every JavaScript asset discovered during recon, attempting to fetch its corresponding .map file and scanning sourcesContent for secrets catches source-map exposure specifically. Capturing response headers that leak version information (Server, X-Powered-By, X-AspNet-Version, X-Drupal-Cache-Tags, X-Generator, and similar) even when the standard security headers are otherwise present catches banner-based fingerprinting risk. Where a GraphQL endpoint exists, a basic introspection query ({__schema{types{name}}}) reveals whether introspection was left enabled in production. Sending malformed input to forms and API endpoints and inspecting the resulting errors for stack traces, raw SQL, or framework banners catches error-triggered leaks. Submitting both known-valid and clearly-invalid identifiers to forgot-password, signup, and chat-widget endpoints and comparing the responses catches lookup-oracle behavior, where the mere existence of an account or contact is inferable from a response differential. For cloud storage, generating bucket names from the target's brand and common naming conventions (<brand>-prod, <brand>-backups) and checking for directory listing or readable content is a reasonable, bounded way to catch open storage buckets. Finally, search-engine dork-style queries (filetype:pdf site:<target>) during recon can surface publicly indexed documents containing PII that were never meant to be crawlable.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Many 200 responses on these paths are catch-all SPA routes returning index.html - content validation per file type is mandatory. /robots.txt, /sitemap.xml, /security.txt are public by design.
• Server-banner findings are informational only, not security-critical, unless paired with a known-vulnerable version.
• GraphQL introspection-on is not always a finding (it is sometimes intentional in dev) - emit informational and let reviewers gate.
• PII doc detection via search engines should flag for human review rather than auto-emit, due to false positives from press releases.

Manual Testing Methodology

Here is a systematic approach to identifying Information Disclosure vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Information Disclosure specifically, trigger error conditions deliberately (malformed input, missing parameters, invalid content types) across every endpoint, and diff full API responses against what the client UI actually uses to spot over-fetched fields.

Compare the response against your baseline, looking specifically for stack traces, internal paths, query fragments, or extra object fields appearing in a response that a production client was never meant to receive.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Information Disclosure, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Information disclosure covers a wide range of severity on its own — a verbose error message, a debug endpoint left enabled in production, or an API response that returns more fields than the client needs can each range from a minor hygiene issue to a direct path toward a more serious exploit, depending on exactly what leaks.

Stack traces and debug output routinely reveal framework versions, internal file paths, and database query structure that meaningfully narrow down what an attacker needs to guess for a follow-on attack like SQL injection or a known-CVE exploit. API responses that over-fetch — returning an entire internal object instead of an explicit response schema — have repeatedly leaked fields like internal user IDs, other users' partial data, or feature flags that were never meant to be client-visible.

Because each individual disclosure often looks low-severity in isolation, this class is frequently under-triaged relative to its role as a reconnaissance and chaining primitive in a larger attack.

Prevention and Secure Coding

Preventing Information Disclosure takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Generic errors to the client, full detail server-side only. Return a generic error message and a correlation ID to the client; log the full stack trace and context server-side where the client can't reach it.

Disable debug/development modes in production. Framework debug modes, verbose stack traces, and admin/debug endpoints should be unreachable in a production deployment, enforced by configuration that's verified as part of the deploy process, not just documented.

Explicit response schemas. Define exactly which fields an API response returns rather than serializing an internal model object directly — this prevents new internal fields from becoming externally visible the moment someone adds them to the model.

Strip identifying metadata. Remove version banners, framework comments, and internal hostnames from responses and headers where they serve no client-facing purpose.