How to Control Top API Security Risks

Here are some things to consider as you plan your API security strategy to ensure you’re protected.

Authentication

This is an obvious one but we’ve seen plenty of high profile breaches where this was missed. T-Mobile back in May of 2018 comes to mind as a recent one. If you don’t have authentication you’re basically leaving the door wide open to attackers and inviting them to come in.

While authentication is table stakes for API security it can give you a false sense of being truly secure. For many applications, especially those that are public facing, it’s trivial to sign up and get legitimate credentials. In a matter of minutes (less time in some cases) an attacker can have a legitimate username and password and begin poking around your API. For public APIs it’s like putting a lock on your door and then giving the keys to anyone who asks. The barrier to entry for developer facing APIs isn’t much higher and we can’t discount how trivial it can be for a determined attacker to get a set of credentials through phishing or other means.

Authorization

After authentication you can control what can be done via API through authorization. For example, is this user or entity allowed to make a specific API call to do something like request data from a database. While this seems to be the end all be all it’s easier said than done. APIs create a complex web of logic that is unique to each application. The logic within a single application alone is enough to make a security admin’s head spin but think about how that complexity increases as you connect multiple applications together via API. Add on top of that the various roles and authorization requirements of users, admins, developers, etc… and that web gets even more complex. Ensuring you have comprehensive authorization policies in place that don’t break your application, especially in a constantly changing environment, can make you feel a bit like Sisyphus.

Rate Limiting & Throttling

Another approach to API security is to limit the amount of activity that can be performed against the API by a user or entity. This can be useful to stop volume based attacks with the intent of performing a denial of service (DoS) or for those that are driven by bots with a goal to scrape sites of data. While these are legitimate concerns they’re not applicable to every application as they primarily target high profile organizations that have a lot to lose should their site go down or if their products/services can be replicated by another site (think retailers, airlines, travel sites, etc…)

‍

‍

‍

Shifting Left

With an effort to ensure anything that goes out the door is as secure as possible organizations have taken to a host of options that include code scanning, penetration testing and even making developers more security minded through security training. While every little bit helps when it comes to security these solutions can be complex, time consuming and expensive, requiring lots of expertise and often leaving gaps. For example, because of the expense of penetration testing organizations may only focus tests on a specific area of an application leaving the rest of the application untested. Considering code scanning, these solutions often generate a lot of noise by providing a list of API security vulnerabilities that may not be exploitable and are therefore lower priority. Sorting these from the higher priority vulnerabilities in order to fix them with limited development resources can be a challenge. Finally ,when it comes to developers, anything that makes them smarter about security is great but they’ll never think like attackers who look for devious ways to misuse APIs to get results. That’s not to say these efforts are wasted but rather they’re not enough, especially considering the types of attacks that are becoming the norm.

‍

You’re Still At Risk

While all of these approaches provide layers of security each can leave a gap for attackers who often use subtle methods to garner significant results. For example a single attacker with a carefully crafted API call can overwhelm an application to the point of an outage. This type of DoS does not require the time or expertise needed to orchestrate a distributed attack and can be done in such a way that it flies under the radar of the other security solutions in your stack.

Another threat is that of data exfiltration. As with the DoS, the right API call can get an application to cough up a trove of sensitive personally identifiable information (PII). This not only has PR implications but can also hit your pocketbook (read about the potential $1.63B GDPR fine for Facebook). Again, these calls go under the radar of the current solutions in your stack and these two examples only scratch the surface of what attackers are after when they target your APIs.

‍

How To Stay Protected & Control Top API Security Risks

As mentioned, there is no silver bullet to protect you from API security risks. With attackers using subtle methods to probe APIs looking for holes, a solution is needed that can understand your APIs at a very granular level, understand what normal behaviour looks like and identify malicious deviations from that normal behaviour. Identifying and stopping attackers as they poke around during reconnasense is key to preventing immediate threats but equally important is fixing vulnerabilities in the APIs themselves to prevent future API attacks. Being able to identify and eliminate those vulnerabilities that have potential to be exploited and are the highest priority are key to making sure that you’re making the most of your developer resources.

To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.

‍