information-disclosure

Information Disclosure Detection

Overview

Information disclosure is an application volunteering data to a caller who should not receive it. Unlike most classes it has no single point in the request lifecycle: it surfaces in response headers, in error bodies, in comments left in shipped markup and scripts, in artefacts that a build copied into a served directory, in diagnostic endpoints that were never meant to survive development, and in behavioural differences between responses that reveal internal state without revealing content. The attacker is an ordinary or entirely unauthenticated user reading responses, often while probing for something else. What they gain is either the sensitive data itself — customer records, credentials, keys — or the technical detail that turns a speculative attack into a documented one: a component version with a published exploit, an internal header name, a directory layout, or the application's own source. This skill finds such leaks by locating every site that can emit internal detail, verifying each one in parallel, and merging the results into <output_dir>/information-disclosure-results.md.

What it is NOT

• Access control (/websec:access-control): pulling another user's object through a missing ownership check. Test: if the attacker supplies an identifier and receives the record it names, the missing control is authorization. Disclosure proper is the application offering data nobody asked to be authorised for.
• Authentication oracles (/websec:authentication): differing messages, statuses, or timings at a login, registration, reset, or change endpoint. Those are judged there, because the fix and the impact are flow-specific. Response differences at other lookups are judged here.
• Injection (/websec:sql-injection, /websec:nosql-injection): a verbose database error is the clue an injection attack uses, not the attack. Report the higher-impact finding there and record the error verbosity here only as its own leak.
• Traversal and upload (/websec:path-traversal, /websec:file-upload): reaching an arbitrary file through a sink that takes a path from the request, or retrieving an uploaded file. Here the file is simply served, because it sits inside a served directory.
• Header reflection (/websec:host-header): a request header echoed into a generated address or a cache key. Diagnostic methods that echo the whole request are judged here.
• Secrets in a signed token payload (/websec:jwt): note it here as a data-handling leak and let the sibling skill judge the token mechanics.
• Private data reachable through a cache (/websec:web-cache-deception): if a response is only exposed because a shared cache stored it under a key another party can request, the defect is in the caching rules, not in what the application chose to include. Test: remove the cache and ask whether the data is still exposed to the wrong principal — if not, it belongs there.
• Credential material in the repository or a client artefact (/websec:secrets): a key, token, or password committed to source, configuration, a pipeline definition, or built into a bundle, an image layer, or a mobile package. Test: does the value reach the attacker because a running process emitted it, or because it is baked into a file the repository or the build produced? The first is here; the second is theirs.
• Protection that was breakable rather than absent (/websec:crypto): a field exposed because the cipher, hash, or random source protecting it fails. Test: was there a control that broke, or was there no control? Nothing applied is here; a control applied with parameters that make it breakable is theirs.
• Cross-origin readability of a response (/websec:cors): a response whose contents are fine for its intended caller but readable by an attacker's origin is a sharing-policy defect. Test: is the problem the data in the body, or who the browser lets read it? The second is that skill's.
• Not a finding: a version banner for a component with no known issue; a documented public API metadata endpoint; a listing of a directory holding intentionally public assets; a public profile field; an example configuration file that carries only placeholder values. Presence alone is never the finding — reachability and gain must both be shown.