Mass assignment and excessive data exposure create two common API security problems. One lets attackers send fields they should not control. The other lets them receive data they should not see. Both flaws can hide behind normal application behaviour. Direct API testing helps prove whether attackers can exploit them.
Two risks with a common theme
Mass assignment and excessive data exposure both involve APIs handling more data than they should.
Excessive data exposure happens on the way out. The API sends more information than the client needs.
Mass assignment happens on the way in. The API accepts fields that the client should not control.
Both problems can come from convenience.
Developers may return a complete data object instead of selecting specific fields. They may also accept every field in an incoming request instead of allowing only approved fields.
The application can work normally in both cases.
The security problem appears when an attacker calls the API directly.
Excessive data exposure
Excessive data exposure happens when an API returns more data than a client needs.
Developers sometimes rely on the application or front end to hide sensitive fields. The API may return a full user record, while the application only shows the user’s name and email address.
That creates a problem.
An attacker does not have to use the application interface. They can call the API directly and inspect the full response.
For example, an application may show a user’s name. The API response may also contain internal IDs, account details, permissions, or other sensitive fields.
The front end may hide those fields. However, the API has already sent them to the client.
Attackers can therefore access data that the application never intended to display.
The API itself must decide what data each user can receive. Client-side filtering does not provide enough protection.
Mass assignment
Mass assignment creates a similar problem on the input side.
An API may automatically map fields from a request to an object in the application. This can make development faster.
The problem starts when the API accepts fields that the user should not control.
Imagine an API that lets users update their profile.
A normal request might include:
- Name
- Email address
- Phone number
An attacker could add another field, such as role=admin.
If the API accepts that field without checking it, the attacker may change their own privileges.
The attacker did not need to break the authentication system. They simply sent a field that the API should have rejected.
This makes mass assignment a serious authorisation problem.
The API must control which fields each user can change.
Why these risks are common
Both risks often come from convenience.
Returning a complete object can take less development work than selecting each field. Accepting all incoming fields can also make updates easier to build.
Frameworks can make these patterns even easier to use.
The problem is that convenience can create weak security boundaries.
These flaws can also pass normal application testing.
A user can view their profile and update their details without any obvious problem. The security gap only appears when someone sends a different request directly to the API.
That is exactly what an attacker does.
They do not have to follow the normal application flow. They can change the request and see how the API responds.
How to prevent excessive data exposure
Start by controlling the data each API response can return.
Do not send an entire data object when the client only needs a few fields.
Instead, define the fields that each response should contain.
The API should also check whether the user has permission to access those fields.
This keeps sensitive data on the server instead of sending it to the client and relying on the front end to hide it.
Security teams should also test API responses directly.
Check what the API returns for different users and roles. Look for fields that the application does not need to receive.
How to prevent mass assignment
Control which fields each API operation accepts.
Do not allow the API to accept every field from a client request.
Instead, define the fields that each user or role can change.
For example, a standard user may change their name and phone number. They should not change their role, permissions, account status, or other administrative values.
The API should reject fields outside the approved list.
This approach keeps the security decision on the server.
It also prevents attackers from adding unexpected fields to otherwise valid requests.
Why testing the API’s behaviour matters
Both flaws can look harmless during normal application use.
The application may show the right data. It may also update the right fields.
The security gap appears when someone interacts with the API directly.
That is why API security testing needs to examine actual API behaviour.
Testers can send requests with unexpected fields. They can also check whether responses contain information that the client should not receive.
Validated testing goes further.
It proves whether an attacker can access restricted data or change values they should not control.
This provides stronger evidence than a configuration check or automated scan alone.
APIs also change over time. Teams add new fields, endpoints, and functions.
Each change can create a new exposure.
Continuous validation helps teams check that these controls still work as the API evolves.
To find excessive data exposure and mass assignment in your APIs, explore our API security capability. You can also learn how continuous service validation keeps API security checks current.
For the wider set of API risks, see the OWASP API Security Top 10.
Frequently asked questions
What is excessive data exposure in an API?
Excessive data exposure occurs when an API sends more information than a user or application needs. Attackers can call the API directly and view fields that the front end tries to hide.
What is mass assignment?
Mass assignment occurs when an API accepts fields that a user should not control. An attacker may add fields such as a role or account status and try to change values they should not control.
Why are these risks so common?
Developers often choose simple ways to handle data. An API may return a full object or accept many fields at once. These choices can create security gaps when the API does not enforce strict data rules.
How do you catch them?
Test the API directly instead of relying only on the application interface. Check which fields the API returns and which fields it accepts. Validated testing can then prove whether an attacker can access or change restricted data.
Request an Attack Insights demo
See how Attack Insights helps security teams discover, assess, and validate API exposure.
