Information disclosure in REST APIs

A web application usually protects its views (login, role-based authorization), but its REST API often does not apply the same control. Endpoints like /api/user/, /api/users, /api/v1/accounts may return full internal objects, including sensitive fields the frontend never shows: cleartext passwords, hashes, tokens, emails, roles.

Discover the API

The pattern is locating the API root and walking the resources it offers. Auto-generated documentation is usually the quickest mine:

feroxbuster -u http://<ip>:<port>/ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt
curl -s http://<ip>:<port>/api/ | jq                     # API index
curl -s http://<ip>:<port>/swagger.json                  # or /openapi.json, /api-docs, /swagger-ui/
curl -s http://<ip>:<port>/api/v1/users | jq

A swagger.json/openapi.json lists all endpoints, their parameters and their schemas: it is the complete map of the attack surface. For hidden parameters, arjun discovers them by brute force.

GraphQL

If the API is GraphQL (/graphql, /graphql-api), introspection reveals the whole schema (types, fields, mutations), including those the interface never uses:

curl -s http://<ip>/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{__schema{types{name fields{name}}}}"}' | jq

When the endpoint responds with the user table and their cleartext passwords, the jump to access is immediate: those credentials usually work on other services (SSH, panel, VPN) through credential reuse.

Requirements

Reachability to the API and it exposing data without proper authorization. Not every unauthenticated API is a leak: some endpoints are public by design. What is serious is exposing fields that should be filtered (passwords, PII) or that require role-based authorization.

It is a variant of Broken Access Control / Excessive Data Exposure from the OWASP API Security Top 10: the flaw is not only missing authentication, but the serializer returning more fields than the client should see. Different from IDOR (accessing others' resources by manipulating an identifier), here the problem is exposing sensitive data en masse.

How to detect it. On the server side, the signature is enumeration: one source walking many endpoints (feroxbuster/dirsearch generates hundreds of requests with a tool User-Agent and bursts of 404/403), a GraphQL introspection query (which no client app issues in production), or accesses to swagger.json/openapi.json from an external IP. Large 200 responses on /api/users to an unauthenticated client, or the full download of a collection, are the exfiltration signal.

Defence. Apply the same access control as the frontend, return only the necessary fields (explicit DTOs/serializers, never the whole model), never store or return passwords in cleartext, disable GraphQL introspection in production, and authenticate/authorize every endpoint. Related to secrets in source and broken access control.