exploiting-excessive-data-exposure-in-api

Intercept API responses with a proxy like Burp Suite or mitmproxy, then compare returned fields against what the UI displays. Scan responses for sensitive field names and PII regex patterns such as SSNs, credit cards, and password hashes.

It is an OWASP API Security Top 10 category covering cases where APIs expose object properties users should not access. Excessive data exposure occurs when endpoints return full database objects and rely on client-side filtering instead of server-side field restriction.

Yes. The workflow includes GraphQL introspection queries to enumerate all fields on types like User, then attempts to query sensitive fields such as passwordHash and mfaSecret to verify whether field-level authorization is enforced.

You need an intercepting proxy (Burp Suite Professional or mitmproxy), Python 3.10+ with the requests library, and two test accounts at different privilege levels. An OpenAPI specification helps compare documented versus actual response schemas.

No. HTTPS protects data in transit but not from the authenticated client itself. Any user with a valid session can intercept their own API traffic and read every field the server returns, including sensitive fields the UI hides.

Do not use it without written authorization specifying target endpoints and scope, since testing involves capturing potentially sensitive personal data. It also does not cover server-side authorization logic flaws like BOLA, which require separate object-level testing.