API3:2019 Excessive Data Exposure: Understanding the Risks, Impacts, and How to Prevent It

What is API3:2019 Excessive Data Exposure?

Excessive data exposure occurs when APIs reveal more fields, data, and information than the client requires through the API response.

Excessive data exposure flaws expose all object properties to API calls rather than what the user needs to act on without considering the object’s sensitivity level.

This vulnerability exposes you to data leaks, man-in-the-middle attacks, and other cyber threats. That is why excessive data exposure in APIs is listed as #3 in the OWASP API Security Top 10 2019.

For example:

In this example, the response includes sensitive information, such as the user’s social security number and credit card number, and unnecessary information, such as the user’s last login IP and timestamp, creation, and update timestamps, and role and permission details.

Exposing this excessive data can risk the user’s personal information and increase the API’s response time and bandwidth usage.

OWASP API Top 10 2023 RC: What’s Different in the Latest Version?

The OWASP API Security Top 10 2023 Release Candidate has just been launched, featuring a range of updates and enhancements over its 2019 predecessor.

OWASP API Security Top 10 2023  has combined excessive data exposure and mass assignment risks into a category called Broken Object Property Level Authorization, which deals with challenges in defining and enforcing access control at a more detailed level.

Why Does Excessive Data Exposure Happen? 

When a user requests the API, it returns relevant objects, data, or functions to the client. Certain assumptions and mistakes made by developers in designing APIs, leaving them prone to excessive data exposure vulnerabilities.

• Developers rely on the client side to filter responses being served to the user and implement them as generic data sources. So, attackers can directly access the data the client UI was supposed to filter out before displaying results to the user. Attackers may use the displayed information to carry out a breach, privilege escalation, or cyberattacks
• Developers assume that the APIs will be accessed only by the company’s clients, who will ignore the additional data displayed. However, attackers (internal and external) will not confine themselves to official clients and will choose to talk to APIs directly if they have a window of opportunity. They will not ignore the additional data displayed.
• Developers automatically leverage programming functions to convert internal API data into responses for improved productivity. While it boosts developers’ productivity, it can also lead to excessive data exposure and API vulnerabilities. And these lead to extra information being displayed to users in the response.
• Improper/ poorly implemented authentication enables users to access sensitive information by exploiting excessive data exposure flaws.

Let us dive a little further using a REST API example.

In REST APIs, the standard structure for API calls includes the domain name, resource, sub-resource, and a specific endpoint. The URL will look like the below:


http://example.com/artists/artist/albums/album1/song4


Users can retrieve, update and upload songs from a specific artist’s album using GET, POST, and PUT requests.

An additional endpoint could be:

http://example.com/artists

– returns the list of all artists.

http://example.com/artists/artist/albums
– return all albums of the artist.

Imagine if, instead of artists, the URL was

http://example.com/users/user1
which is supposed to return basic details like username, email id, and last login details. But the API depended on the front end to filter the response before displaying this to the user.

So, the API could expose more details like full name, phone number, address, etc. Using frontend developer/ browser tools or external tools like Postman; the attacker could retrieve full data about multiple users without any authentication. This is the case with most APIs, leaving them vulnerable to excessive data exposure.

With a REST API path like

http://example.com/user/info
the attacker could guess that other paths like /admin may exist. So, they will come up with a script to check if

http://example.com/admin/info

returns a response. Without proper authentication mechanisms, the API will return admin information, enabling attackers to do their bidding.

Real-Life Attack Scenarios

Example 1: An online retailer’s mobile app sends unencrypted data from the API to the client. An attacker intercepts the traffic between the client and the API. If they see additional information being passed along, they will come up with scripts to scrape the data from the mobile app.

Example 2: An API endpoint for a CCTV app returns the list of all camera endpoints for the entire building for user queries. It relies on the app to filter out the cameras and only those a specific user can access based on access controls. The attacker bypasses the app and directly queries the app to gain access to all CCTV cameras in the building, evading the access control systems.

Example 3: Consider the case of an e-commerce company. The attacker manages to pretend to be an e-commerce app using some hacking tools and software. Using the control over the client (the ecommerce app), the attacker can intercept all data exchanged between the API and client, including those to be ignored/ filtered by the client. So, the attacker sees sensitive information like credit card details, CVV numbers, and so on.

Why is API3:2019 Excessive Data Exposure Dangerous?

The Twitter Breach 

In July 2022, attackers sold the data of 5.4 million Twitter users on a hacking forum. This was followed by news that an attacker had scraped and sold 400 million Twitter users’ public and private data on the dark web. In January 2023, another news was that Twitter was refusing to pay a ransom to attackers threatening to release 235 million unique user records of Twitter users. These unique records included user email ids and phone numbers.

This API breach was a classic case of excessive data exposure flaws exploited by threat actors. Attackers leveraged an API vulnerability that allowed them to feed email ids and phone numbers to the Twitter API to check if it was linked with a Twitter account. The attacker would then use the IDs to retrieve their public profile information.

This breach left accounts of celebrities, politicians, activists, and even anonymous users exposed to social engineering attacks, targeted phishing attacks, etc. For instance, attackers can easily create fake profiles that look close to the actual profiles of high-profile users to run phishing campaigns.

Exploitability 

With an OWASP exploitability score of 3, excessive data exposure in APIs is easily exploitable. It is just a matter of attackers finding a single instance of excessive data revealed in API requests. Once they do, they will leverage automated tools to gain access to large volumes of data through APIs.

Detectability 

As per the OWASP risk rating, excessive data exposure has average detectability (score of 2). Attackers can bypass authentication measures and basic security tools since the requests and responses seem normal and legitimate. Finding these flaws may be challenging unless an API-specific runtime monitoring solution is used.

How to Protect Yourself Against Excessive Data Exposure? 

1. Don’t Rely on the Client Side for Data Filtering 

This is the top preventive measure offered by OWASP to stop API3:2019 Excessive Data Exposure. Data filtering should occur at the API level instead of the client side, especially when dealing with sensitive data. You must completely control your sensitive data, ensuring users access only as much as they require. The client side should only render the data on the screen, not filter responses.

This must happen at the design stage itself. You should craft API responses to all the common API calls. This way, you can limit the data flow to only those a user/ user group can access instead of giving away all data objects.

Even if sensitive data must be returned, you could consider data masking to ensure attackers don’t access sensitive data. You have strict access control, authorization, and authentication measures, especially for users accessing sensitive data.

2. Control and Minimize What API Responses Return 

Your backend systems should not reveal any extra information, sensitive or not, to attackers. You should review all API responses to all calls to ensure they contain legitimate information only. Thereon, it limits the return response from the API, making it difficult for attackers to find excessive data exposure vulnerabilities.

Implement a schema-based response validation mechanism with carefully designed API response schemas, including error responses. This will serve as an extra layer of security and limit your attack surface.

3. Data Categorization 

You must define and categorize what constitutes sensitive data, admin data, and PII. You must justify why they are used and stored. This definition needs to evolve as some data not considered sensitive today may become sensitive tomorrow. Accordingly, your response schema must reflect this.

4. Data Encryption 

All data at rest and in transit needs to be encrypted using strong encryption and hashing protocols. This reduces the likelihood of attackers accessing API databases or intercepting API-client connections to access data.

5. Design Level Measures

A secure SDLC process is key to preventing excessive data exposure in APIs.

• Ongoing developer training is a must.
• They should prevent using generic methods for API responses.
• They should test APIs from the beginning of the development process to find flaws before APIs go into production.

6. Real-Time Threat Monitoring and Runtime Protection 

Attackers can bypass traditional security tools like firewalls and access sensitive information since the requests seem legitimate. You need an API-specific, fully managed security solution like AppTrana to protect your APIs from excessive data exposure.

Through its runtime protection and behavioral analysis capabilities, AppTrana analyzes traffic intelligently to detect anomalous behaviors. Through continuous automated testing and manual pen-testing, it finds vulnerabilities that leave you exposed to data exposure threats.

How Does AppTrana Help?

AppTrana utilizes deep inspection and machine learning to provide real-time protection for APIs, analyzing all traffic flowing to and from the APIs to identify potential security threats.

When inspecting API traffic, our security experts consider API calls that could potentially include sensitive internal API data, including user profiles, groups, and linked users.

Through API discovery, the platform can dynamically generate an inventory of all APIs, even those containing sensitive data in their responses. API discovery can provide better visibility into your API inventory and identify potential security vulnerabilities or weaknesses, enabling you to take action before an attack occurs.

It develops a positive security model based on the API inventory. Any application behavior that diverges from the positive security model is regarded as a potential security risk by the WAAP, which then takes steps to prevent it from executing.

With the ability to recognize various API types, such as REST, GraphQL, SOAP, and gRPC, AppTrana WAAP can detect sensitive data in API responses and even enforce policies against its inclusion. Additionally, the platform includes anomaly detection features to identify suspicious activity, like an unusual surge of requests for a specific API endpoint.

Stay tuned for more relevant and interesting security updates. Follow Indusface on Facebook, Twitter, and LinkedIn