Dan Gordon 
Sensitive Data Everywhere
Every organization that has an internet presence is constantly exposed to cybercriminals who wage campaigns that target their sensitive data. Not long ago cybercriminals used to exclusively target web applications. But with the explosion of cloud-based microservices that use APIs to communicate with each other and the external world, cybercriminal tactics and strategies have shifted.
APIs are increasingly becoming mission-critical for organizations, utilized as a business driver that can generate new revenue streams. The rapid adoption of APIs has been integrated across a complex web of internal applications, external third-party partnerships, and consumer devices, creating a new wide attack surface. Vulnerabilities in business logic can expose weakness that can be exploited, exposing critical business data.
One Profitable Business Model
Cybercriminals have figured out that stealing sensitive data has become a profitable business model. Targeting confidential data such as financial data, healthcare records and Personal Identifiable Information (PII) pays for itself, turned around and sold in the digital black market for considerable profit. Year after year, the size and severity of data breaches has become more pronounced and more public. Stealing headlines, data breaches can be instrumental in affecting the public perception of a company’s brand and management competence.
OWASP API Top 10
The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop trusted and secure applications and APIs. For years they have published the well known list of the top 10 web application security risks, known as the OWASP Top 10.
The problem of exposing sensitive data is not a new issue. In fact, inadvertent exposure of sensitive data has been such a constant issue with the growth of the internet that the OWASP Top 10 list places “Sensitive Data Exposure” as number three.
With the hypergrowth of APIs a new problem is emerging that is further adding fuel to this fire – excessive data exposure. In order to save time, developers are writing APIs in such a way that raw data is exposed in communications from the server backend to the end client. Imagine that the end client is an app on a smartphone accessing the server backend in the cloud. Rather than write specific responses in code, the backend server sends raw chunks of data to the client, who is then tasked with filtering out the data it actually needs. This is all done without taking into account the sensitivity of the exposed data. A clever attacker can sniff the traffic and obtain sensitive data such as credit card information, Social Security and phone numbers, and access tokens.
APIs have become such a prevalent new attack surface that OWASP began publishing a new list focusing on the top 10 API vulnerabilities, called the OWASP API Top 10. In the last several years “Excessive Data Exposure” has steadily risen to the top of the OWASP API Top 10 list, currently sitting as the third most critical attack vector.
How To Protect Against Excessive Data Exposure
There are five steps that can be implemented to help mitigate excessive data exposure when developing APIs.
1. Stop Clients from Performing Data Filtering
Clients shouldn’t be in the business of performing data filtering. APIs are often designed to send more data to the client than is really required. True, this can help a developer save execution time by not having to craft specific responses to data requests, and instead just send generalized JSON payloads. But by sending raw data from the backend systems to the client, the onus is on the client to filter out the relevant data it needs. Attackers can intercept this raw and unfiltered traffic, looking for sensitive data or information that can be used to penetrate an organization’s security defenses.
2. Minimize Return Responses
Backend systems can return information in response to client requests that expose information on platform technologies used by the application. Attackers often use this information to look for vulnerabilities on software or open-source components that can be used for a deeper and more focused attack. Minimizing return responses helps reduce the attack surface and makes it harder for the attacker to get a complete understanding of the systems being used and discover critical vulnerabilities.
3. Use Careful API Design
Protection from excessive and sensitive data exposure should start early in the API design process. Carefully define API use cases to ensure that just the minimum amount of data is sent in the response payload. A positive security approach that lists all the characteristics of allowed requests can help to limit a hacker’s ability to penetrate business logic and steal sensitive data. These defined characteristics help to validate input and output data by predefining min or max length, permitted characters, or valid values ranges
4. Adopt and Maintain OpenAPI or RAML standards.
The Open API and RAML (RESTful API Modeling Language) standards are part of a driving movement to bring structure and order to the API development process. Developing detailed and valid API specifications that follow Open API and RAML can provide an additional layer of security in the form of policy that monitors data returned by all API methods, including errors to conform to the specification. But also be aware that using them effectively requires organizations to constantly keep them fresh or run the risk of protections becoming outdated.
5. Automate API Discovery and Tracking
A new category of security API products are emerging that respond to these evolving challenges. The security platforms help automate the difficult task of not only cataloging APIs but also discovering changes to the APIs themselves, such as minute alterations to character limits or JSON object sizes that can be allowed to transfer between client and server. They can go even further by allowing security teams to monitor end-to-end API transactions from the client all the way through the dense ecosystem of microservices to the back-end data. This fresh approach provides a crystal clear security picture of the ever-changing state of your API environment, without the manual burden of tracking and monitoring API development and transaction activity.
Next Steps
The size and complexity of APIs continue to expand, intertwined with the growth of cloud applications and maturing of the digital economy. These have become essential parts of our daily lives.
New approaches and best practices are emerging that can better secure against the vulnerabilities that have accompanied API development, such as excessive data exposure.
Developers should continue to use security best practices for APIs when designing and developing APIs, such as minimizing data exposure and documentation of API changes. But it is also clear that more of a safety net is needed to protect our data, and for that tools that automate API discovery, tracking, and protection should be considered.
About the Author
Muzaffer Pasha is an application security specialist and regular contributor to The Inside Trace.
View a recorded demo of Traceable Defense AI.
