An API is essentially a tool to provide an interface for the client with the software—that's what they do.
Some of the API methods modify application state and some return data to the client. Further, some methods can do both. Once we return data to the client, we need to make sure that we return only what's necessary and don't expose any sensitive information.
This post will cover excessive data exposure in APIs with examples and prevention methods. The examples will be given in the context of the Java Spring framework.
REST API Structure
Usually, REST APIs follow a standard structure for the API calls. The structure usually consists of a domain name, a resource, a sub-resource, and a specific endpoint. For instance, a URL that looks like this— http://domain.com/artitsts/artist/albums/album1/song3—will allow a user to use different HTTP methods (GET, POST, PUT) to retrieve, update, and upload songs from a specific album for a specific artist.
Additional endpoints can be http://domain.com/artitsts/albums/album1, which will return a list of all the songs in an album, and http://domain.com/artitsts, which will return a list of items.
API Structure-Sniffing Vulnerability
The first vulnerability associated with this structure and excessive data exposure can occur if an attacker guesses or receives a list of endpoints.
If an endpoint that exposes sensitive data doesn’t require authentication, as explained here, the attacker can gain access to data he's not authorized to view.
That said, the attacker can use brute force to identify API endpoints. This can be achieved by randomly trying to generate URLs that'll return a response, or by using a list of popular paths to see if the server returns a response for them.
For instance, a popular REST API path is /users/info. Another one is /admin. So, the attacker will create a script that checks those paths combined with a domain name—http://domain.com/users/info, http://domain.com/admin—and see if any of them returns a response.
Another Way of Sniffing API Structure
The REST API standard includes a specification called HATEOS, which basically means that every API response should return a list of links to other API endpoints that can be relevant to this specific endpoint.
If the API developer just blindly returns a list of all the API endpoints in the system, or returns API endpoints that should be password protected but aren't, he exposes data for attackers.
An example of a HATEOS response, taken from the relevant Wikipedia entry, is
HTTP/1.1 200 OK
{ "account":
{ "account_number": 12345, "balance": { "currency": "usd", "value": 100.00 },
"links":
{ "deposits": "/accounts/12345/deposits",
"withdrawals": "/accounts/12345/withdrawals",
"transfers": "/accounts/12345/transfers",
"close-requests": "/accounts/12345/close-requests" }
}
}API Endpoint Sniffing
Another way for the attacker to gain access to sensitive information doesn't even require any extra effort of sniffing for undocumented API methods.
If the API endpoint returns more info than required and relies on the fronted developers to filter the extra data, that basically means that for an endpoint like this—http://domain.com/users/user1—that should return some basic details like username, email, and last login date, and the server returns additional data like a full name and address.
The server relies on the front-end developers to filter out the unwanted information and present in the browser/app only the basic details that should appear there. However, the attacker can use the browser's developer tools or do an API request with an external tool (like postman) and see the full data that the server returns. So, where a regular user will see something like this
HTTP/1.1 200 OK { "user:
{ "username": "john doe", "email":"johndoe@gmail.com" }
{
the attacker will see the full output:
HTTP/1.1 200 OK { "user:
{ "username": "john doe", "email":"johndoe@gmail.com",
"name: John Doe Smith", "address": "Smith's road 1, NY, NY" }
{Protecting Against Excessive Data Exposure
What makes data sensitive and what manifests excessive data exposure is highly context-based. What constitutes excessive data in one API is a perfectly reasonable response from a different API.
Thus, it means that automated tools usually can't help you with identifying and mitigating this vulnerability. It's up to the developer to harden the API to protect against this vulnerability.
Vulnerability Mitigation
First, I'll provide some general guidelines for mitigating this vulnerability. After that, I'll provide some Java Spring-specific examples.
1. Never Rely on the Front End to Sanitize Data
The back-end developers that implement the API should be the ones that return only nonsensitive data. You shouldn't rely on the front end to filter out that data.
Even if front-end developers properly filter out the unwanted data, as seen above, an attacker can access the whole response by accessing the API independently.
I'll provide an example of how to avoid returning excessive data in an API response in Java Spring in the next section.
2. Protect API Endpoints That Require Authentication and Authorization
As I've described, you should protect with authentication and authorization each API endpoint that should return sensitive data.
3. Don't Expose All API Endpoints Via HATEOS
If you implement HATEOS as part of your REST API, don't return the whole list of API methods. Hence, return only a list of those methods that are relevant for the specific endpoint.
Spring Boot
The Spring framework is a superb Java framework for creating web applications and enterprise applications.
In 2005, Pivotal developed the Spring framework, and it's still very popular today. Ever since Pivotal developed the Spring framework, they've added various modules to the core Spring container.
Spring Boot is one of the most commonly used ones, representing the convention over configuration part of the Spring framework. Spring Boot lets you code with very minimal configuration.
Mitigating Excessive Data Exposure Vulnerability in Spring Boot
Let's return to the API example of a user endpoint discussed earlier:
HTTP/1.1 200 OK { "user: { "username": "john doe", "email":"johndoe@gmail.com", "name: John Doe Smith", "address": "Smith's road 1, NY, NY" } {We can represent it in Spring Boot using the following class:
public class User {
private String username;
private String email;
private String fullName;
private String address;
}As I mentioned earlier, we want the API to respond only with the username and email. To do this, we can add the @JsonIgnore property to the fields we want to exclude in the API response:
public class User {
private String username;
private String email;
@JsonIgnore
private String fullName;
@JsonIgnore
private String address;
}This prevents the fullName and address from appearing in the response.
Conclusion
APIs are the backbone of many applications and websites. They provide critical services to clients.
Excessive data exposure vulnerability is a serious vulnerability that can pose a security risk to an organization. In this post, I've shown the way that this vulnerability is exploited and different attack vectors.
Likewise, I've added some standard ways to mitigate it, with a specific example for Java Spring Boot. Founded in 2005, this is a very popular framework for creating Java back-end applications, and it's still one of the most popular frameworks in the Java world.
Don't rely on the front end to filter out sensitive data; instead, manually go through your endpoints and make sure that you return only the necessary data.
In addition, avoid providing links for all the methods in the API, unless you're building an API documentation and, in general, harden your API as much as possible.
This post was written by Alexander Fridman. Alexander is a veteran in the software industry with over 11 years of experience. He worked his way up the corporate ladder and has held the positions of Senior Software Developer, Team Leader, Software Architect, and CTO. Alexander is experienced in frontend development and DevOps, but he specializes in backend development.
