Information Disclosure

Why It Matters

The server constantly tells you more than the browser shows. A modern frontend receives a full JSON error and renders only the friendly message field, silently dropping the stack, the database exception, and the debug detail. Read the raw response in an intercepting proxy such as Burp Suite and that hidden detail becomes free reconnaissance.

Information disclosure is one of the most common findings in bug bounty and the quiet first step in many real breaches, because it converts guesswork into a targeted attack. It is catalogued as CWE-200 and underpins the reconnaissance phase of almost every web assessment.

Common Sources

• Stack traces: leak the language, framework, file paths, and line numbers, often from an unhandled exception.
• Database errors: leak the engine, database name, tables, and columns, the perfect setup for SQL injection.
• Verbose headers: Server and X-Powered-By banners reveal software and versions an attacker can match to known CVEs.
• Over fetching APIs: endpoints that return more fields than the UI displays, sometimes including other users' data or internal flags.
• Source maps, comments, and debug endpoints: expose internal logic, hidden routes, and occasionally hardcoded secrets.

A Worked Example

A login form shows the generic message "the email or password provided is incorrect". The same request in a proxy returns a 401 whose JSON also carries a stack field pointing to /home/app/node_modules/payload/dist/auth/operations/login.js. In one failed login the tester now knows the runtime is Node.js, the framework is Payload, and the exact server paths, none of which the browser displayed. That detail guides every test that follows.

How Attackers Use It

A leaked framework name points to known vulnerabilities. A leaked file path lets an attacker guess other endpoints. A leaked table and column name turns a blind injection attempt into a precise UNION SELECT. The disclosure itself may seem harmless, but it removes the uncertainty that protects most targets, which is why triagers still reward it even when no further exploitation is shown.

How to Test for It

Trigger errors on purpose and read the raw response. Submit unexpected types, remove required fields, send malformed JSON, request missing resources, and compare a 500 response against a normal 200. Inspect every header, look for fields the UI never displays, and check /.well-known/, source maps, and verbose API responses. The habit that matters is reading the response the server actually sent, not the page the browser drew.

Prevention

Show users generic errors and keep the detail in server side logs. Disable debug output in production, strip version banners, and ensure APIs return only authorized fields through explicit response models. Crucially, test your own application through a proxy so you see the raw responses your users' browsers are hiding.