API Best Practices: Security

How to ensure your APIs aren't naked

SaiJoel

Sep 26, 2016

Over the last few years, we’ve witnessed hundreds of enterprises launching API initiatives. This post is the first in a series that aims to distill our learnings from all these customer engagements and share best practices on a wide variety of topics, from deployment models to API design to microservices.

Organizations have used web application firewalls and DDoS protection solutions to secure their web apps. In the world of mobile, cloud, and microservices, where enterprise data is accessed with APIs in a zero-trust environment, what’s needed is deep API security. At risk are hundreds of thousands of sensitive customer records or millions of dollars.

There are known threats. The Open Web Application Security Project (OWASP), an online community of application security researchers, publishes an annual list of the top 10 security threats enterprises face. But there are also potential attacks from “unknown” threats—software that constantly scans for vulnerabilities in application infrastructures.

For protection against all kinds of external threats, organizations should create proxies in front of their APIs with an API management platform and enforce a set of consistent security policies at the API proxy layer. So, let’s review typical types of cyber threats and how organizations secure their APIs.

Injection threats

These are common. Attackers trick an application to divulge sensitive information by including malicious commands as part of data input. For example, by sending strings like " OR 1==1 -- " as a data input, hackers could bypass user authentication in the application like the code snippet below:

Broken authentication and session management attacks

These attacks steal session IDs or tokens from your app user’s device and enable hackers to take over a user account. To mitigate such attacks, enterprises use out-of-the-box two-way TLS and OAuth2 policies to implement standard OAuth2 and enforce two-factor authentication.

Cross-site scripting (XSS)

Cross-site scripting involves a hacker executing malicious code on behalf of an innocent user by hoodwinking the user to click on compromised URLs.

Instead of http://example.com/account?item=543, for example, the hacker could get an innocent user to execute something like

Executing this script, the mobile client using the API could allow an attacker to steal the user’s authorization token or cookie. This vulnerability exists in many web apps and mobile apps that use webviews. Hackers can use the innocent user’s token or cookie to log in into your systems and steal sensitive data.

With each of these attack vectors, the hacker modifies an existing API request pattern to either access objects they shouldn’t or request access at a different level (user versus admin) in your apps.

For example, realizing the API is of the form https://api.awesomeretailer.com/user/account/1234, hackers could attempt a series of API calls by changing the account number (for example, https://api.awesomeretailer.com/user/account/5432 ) to access other accounts. Or they could try to gain access using https://api.awesomeretailer.com/admin/account/5432

With OAuth2 and the right scopes set for APIs, organizations can easily reduce the attack surface and mitigate risk without refactoring existing applications.

Sensitive data exposure

When web and mobile applications store sensitive data like credit card information and passwords insecurely, problems arise. By building secure API proxies for your sensitive APIs, you create a secure facade in front of your applications. Using a PCI- and HIPAA-compliant API platform, organizations create secure proxies and also ensure API keys are stored in encrypted mode.

Cross-site request forgery (CSRF)

In these attacks, hackers exploit the trust that an application has in a user’s identity after the user initially logs into the app (a banking app, for example). The hacker would have sent this innocent user an HTML email with a tag like

If this “image” is loaded automatically, the user’s client would make a transfer request with the exact IP address and session cookies or token; it would appear as if the innocent user has made the call. From the app perspective, it would look like a legitimate request, and it would send $5,000 to the hacker’s account.

This kind of attack is mitigated by adding special CSRF tokens or by reducing the attack window with expiring tokens and using two-way TLS to avoid token leakage. Organizations have implemented it with a set of secure API proxies for all their sensitive APIs.

Beyond the above known OWASP threats, organizations also need to protect themselves from volumetric attacks like denial of service (DoS) attacks. Enterprises use spike arrest and rate-limiting policies at the API proxy layer to mitigate risk from such volumetric attacks.

Adaptive threats

Besides the various known threats, increasingly we need to tackle “unknown” threats, where automated software programs called “bots” can constantly scan for security vulnerabilities in your app infrastructure.

A sophisticated API platform continuously monitors your web and API traffic. It identifies bots by using API access behavior patterns, rather than IP addresses. As a result, bots can be tracked even when they change location.

Advanced API platforms uses sophisticated machine learning algorithms on data aggregated across multiple customers. As it analyzes billions of API calls, it can distinguish legitimate human traffic more effectively than possible from a single source of data.

Once it identifies API call pattern that has a “bot like” signature, it flags it. You can then specify the action to take for each such identified “bot signature.” The API platform would then automatically take appropriate actions like blocking, throttling, or honeypotting.

It is pretty easy to stand up a set of APIs for use for your mobile apps teams or partners, but it takes a lot more to make sure you are not exposing a set of naked APIs.

For protection against all kinds of threats, organizations create proxies in front of their APIs and enforce a set of consistent security policies at the API proxy layer with API management platforms.