Home / Knowledge hub / Excessive data exposure
Knowledge hub
Excessive data exposure
An API sends whole records and trusts the page to show only the safe fields.
What it means
Excessive data exposure is when an API returns more data than the screen needs, and relies on the front end to hide the rest. The page shows a name and a photo, while the response also carries an email address, a phone number and an internal note.
Anyone who looks at the response, with browser tools or a simple script, sees all of it. Hiding data in the interface does not protect it, because the interface is not where the data is held. The leak is in the response, which the person never sees but any tool can read.
Why it matters
It leaks personal and business data without any break-in. The caller is signed in and the request is allowed, so the log shows nothing wrong. It is a path to a data breach and to personal data exposure that shows up in a security review or a customer complaint.
It is easy to create. Developers return a whole database object because it is quick, and a later change adds a sensitive column that now ships to every client. OWASP ranked it third in its 2019 API list, and folded it into BOPLA in 2023.
How it shows up
You meet it in APIs behind web and mobile apps, in GraphQL responses that return a requested field the app never uses, and in search and list endpoints that return more than the detail page does. Compare each response with what the screen shows and look for fields that should not be there.
The fix is to decide what to return per endpoint and role, using output shapes written for the purpose, not the database record. Filter on the server. See BOPLA, which now covers it, and data minimisation for the principle behind it.
Questions people ask
Excessive data exposure, answered
Why is it not enough to hide fields in the front end?
Because the data has already left your server. Anyone can read the response in browser tools or call the API directly, without using your interface at all.
Is it the same as a data breach?
It is a flaw that can cause one. The data goes to an authorised caller who sees too much, which becomes a breach if it is collected at scale or by someone who should not have it.
Which endpoints leak most?
List and search endpoints, profile and account pages, export features, and any endpoint that returns a whole object. Mobile app APIs are common because the client was trusted to filter.
How is it found?
By comparing what an API returns with what the screen needs, and by reading responses for fields that should never leave the server, such as hashes, tokens or internal notes.
What fixes it?
Return only the fields each role needs, using explicit response shapes, and filter on the server. Review again when columns are added. Then re-check when columns are added, since a new field can start leaking the same day.
Related
Terms that sit next to this one
Broken object property level authorisation
Seeing or changing single fields of a record that you should not.
PII
Any data that points at a specific human being.
Data minimisation
Collecting and keeping only the personal data you actually need.
API
The part of your application other software talks to, not a person.
GraphQL
One API endpoint where the client asks for exactly the fields it wants.
What does the response really say?
We read API responses the way an outsider would, and report the fields a signed-in account receives that it should not, with the request and response as proof. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.