Excessive Data Exposure, classified as a critical risk in the OWASP API Security Top 10, represents a fundamental failure in API design where endpoints return significantly more object properties than required by the application. In modern development, characterized by the shift toward ephemeral microservices and mobile systems, developers often prioritize generic, quickly deployable, and reusable endpoints. To reduce server-side complexity and processing overhead, applications rely on client-side filtering, assuming it is more efficient to transfer full datasets and let the client handle the application logic.
This new way of designing applications creates an expanded attack surface for threat actors to exploit. Whether using RESTful over-fetching or unchecked GraphQL introspection, it allows malicious actors to intercept API traffic and inspect the raw JSON response, uncovering hidden sensitive information such as Personally Identifiable Information (PII) or other sensitive information. This document analyzes the technical root causes of these exposures, illustrates real-world impact(s) through case studies, and outlines comprehensive server-side remediation strategies to ensure data confidentiality and industry standard best practice compliance according to OWASAP API Security guidelines.
Reference: For the complete list of compliance standards, mitigation techniques, and the full API Security Top 10 framework, refer to the official OWASP project documentation:
- OWASP API Security Project: https://owasp.org/www-project-api-security
- OWASP API #3 (Excessive Data Exposure)
What Is Excessive Data Exposure?
Excessive data exposure is an API vulnerability that comes under the OWASP API Top 10 vulnerability, which happens when the API sends more information than the user actually needs to see or have access to. For example, if the application just needs a username, but the API sends the user’s profile, email addresses, tokens, geolocation, including the address and phone number. This is dangerous because a nefarious actor can intercept the traffic and see the hidden data.
Risk Context: The Modern API Attack Surface
In modern applications, frontend interfaces have permanently changed the security landscape's attack surface. Unlike traditional web applications that rendered HTML on the server, modern APIs frequently function as ways to directly pull information. APIs often include unnecessary information such as authentication tokens, email addresses, or other PII, often delivering more data than the user requires to access the resource intended.
Adversaries utilizing interception tools (e.g., Burp Suite, mobile proxies, or browser DevTools) can now easily inspect the JSON payloads potentially carrying excessive or extra data. This allows attackers to harvest sensitive data for Credential Stuffing, give a leg up on reconnaissance, or even allow a nefarious actor to potentially execute a full account takeover. According to OWASP risk methodology, this vulnerability carries a high business impact rating due to the potential for substantial regulatory fines and long-term reputational degradation.
Reference
OWASP API Security Top 10:2023 Category: API3:2023 Broken Object Property Level Authorization (formerly Excessive Data Exposure)
- URL: https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/
Technical Root Cause: Insecure Data Serialization
This vulnerability typically happens when an API implementation performs direct object serialization instead of utilizing a defined Data Transfer Object (DTO). Sometimes, the backend retrieves a record from the database and serializes the entire entity, including sensitive attributes like PII, directly into the HTTP response body.
The failure occurs because the server relies on the client-side application to filter the presentation of data, rather than restricting the data at the source. While the UI may look correct, the underlying network traffic exposes the full, unfiltered dataset.
Vulnerable Code Example
Why this is not safe: In the above vulnerable code, the backend is returning everything stored in the database for the post. That includes sensitive fields like the user’s email, internal role, or metadata. The frontend may only display the post content, but the API response still leaks unnecessary data.
Safe Code Example
Why this is safe: In the updated code, the backend manually selects which fields to send back. Only the username, content, image, and created_at are returned, and nothing extra. Sensitive data like email, admin flags, or internal metadata remains in the backend and never reaches the client.
Reference: Source: OWASP API Security Top 10:2023 Category: API3:2023 Broken Object Property Level Authorization
- URL: https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/
Real-World Examples of Excessive Data Exposure
Consider an organization directory application where a standard (low-privilege) employee can look up a colleague to see their username, full name, and role. The application requests /api/user/{ID} to retrieve these details.
While the user interface (UI) correctly displays only the public information, the backend API returns the complete user profile.
The Risk: An attacker using browser DevTools or a proxy can inspect this traffic, revealing private contact details or identifying administrative accounts to target for future attacks.
The low-privileged user should only be able to see the username, full name, and role of a certain user using the GET API call /api/user/{ID}
Consider an organization directory application where a standard (low-privilege) employee can look up a colleague to see their username, full name, and role. The application requests /api/user/{ID} to retrieve these details. In such cases, an attacker can simply use tools such as DevTools to see other users’ sensitive details in the response.
As seen in the response above, the API delivers sensitive internal data. This includes their username, fullname, email, and phone number(s). Because the server uses a generic command like res.json(user), it dumps the entire database record into the network traffic.
GraphQL Example
Just like REST APIs, GraphQL can also leak sensitive data if developers expose entire object types instead of required fields.
GraphQL is often used to prevent the client from receiving too much data because it allows clients to request exactly the data they need. However, if the underlying Schema is poorly designed, it becomes a significant source of data leakages. Unlike REST APIs, which typically return a fixed structure that often forces clients to receive more data than necessary, GraphQL gained popularity by allowing clients to request exactly the fields they need. However, this flexibility introduces a unique risk: if the GraphQL schema is poorly designed, it can still expose sensitive internal fields to anyone who knows how to ask for them, even if the legitimate frontend application never queries that data.
In this example, the GraphQL 'User' definition includes sensitive details like email, phone number, and an 'isAdmin' flag. These fields should remain private, but because they are listed in the API's schema, they are accessible. An attacker can simply bypass the app's interface and write a custom query to fetch this sensitive data directly.
Vulnerable Code Example
In the code above the developer has defined the GraphQL User type to mirror the database structure exactly. Because the resolver returns the raw database record without applying field-level restrictions or specific access controls, every field listed is listed, regardless of who queries the data. Now safe or sensitive information becomes publicly accessible to anyone who asks for it.
This safe schema exposes only the fields the application actually needs, instead of returning the full user object. Sensitive fields like email, phone number, and admin status are intentionally removed to prevent accidental data leaks. By defining a restricted GraphQL type like this, the API ensures that clients can query only non-sensitive fields.
What’s The Impact?
When attackers exploit excessive data exposure, they gain unauthorized access to sensitive Personally Identifiable Information (PII), such as emails, phone numbers, or session tokens. This often leads to:
- Account Takeover & Identity Theft: Especially if the exposed fields include API keys or authentication credentials.
- Financial Fraud: If payment history or banking details are leaked.
- Attack Chaining: Attackers often combine seemingly small leaks (like a user ID or email) to launch more complex and damaging attacks later.
How to Prevent Excessive Data Exposure?
Let's have a look at some strategies that you should implement to prevent this vulnerability:
- Limit Data Exposure: Avoid generic serialization methods that return entire database objects (e.g., to_json()). Instead, explicitly select and return only the specific fields needed for each API call.
- Strict Server-Side Authorization: Always verify the user’s role and permissions on the server before returning data. This ensures that users can only access the fields they are allowed to see. Even if someone tries to query the server, the server will block access, preventing exposure of private information.
Final Thoughts
Excessive Data Exposure may appear deceptively simple, but it remains a pervasive vulnerability that quietly leads to high-impact data breaches. The danger lies in the risk. Most data leaks exist solely within the raw API response payloads that the user interface never displays.
For security teams and auditors, the takeaway is clear: never judge an API's security by what appears on the screen. Always inspect the underlying traffic and penetration test your code before production. For developers, the defense is architectural. By shifting from client-side masking to strict server-side filtering, organizations can ensure that sensitive data never leaves the secure backend environment, effectively neutralizing the risk before it reaches the network.
