If you?re involved with launching new apps, you?ve likely heard of ?API Security? ? the need to provide a security model that protects the APIs (and corporate and customer data within them) you expose to developers for mobile/cloud/IoT integration. And yet, some of you will likely point out that applying security to your APIs can take time and perhaps prevent you from being first to market with the latest cool ?thing.?
Sadly, ?cool? and ?timely? almost always trump security.
Some examples of where security took a backseat:
- Snapchat originally decided to use private APIs, bypassing the need to secure APIs (or so they thought). That didn?t work out very well.
- Moonpig chose to use a static credential for login from mobile apps for their greeting card service. The API was easily hacked, exposing customer information and allowing attackers to place orders on customer accounts, view addresses and orders, and more.
- In the connected car world, there?s been significant security fiascos at Jeep and Nissan involving hacked APIs.
- And finally, as Matt McClartypointed out recently, Niantic Labs (makers of Pokémon Go) ?hid? an API rather than secure it, with not very shiny results.
There are many similar stories out there and almost all were because securing APIs would take extra time, delaying product availability.
Looking at the examples I provided, we can see that when an API is exposed, vulnerabilities begin to surface. Data can be exposed. If it?s corporate IP, it can damage the company ? but if it?s customer data, it can destroy the company.
Avoiding and Reducing Risk
So how do you fix this? Start with a risk assessment. What is your risk, and what will you do about it? Every enterprise has different risks, based on the application, the back end, the identity model, and the endpoints.
How do you determine your risks? Simple ? evaluate your assets, known vulnerabilities, and known or possible threats. This gives you a pretty solid picture of your risks. From there, you can hopefully implement measures to avoid them or reduce them.
An excellent way to avoid or reduce risk is by using a hardened API gateway that allows you to implement security models with minimal impact on your developers (whether internal or external). This provides the foundation to protect your APIs end to end, and for many enterprises, provides the additional functionality necessary to connect legacy systems with modern apps and devices. And the right solution will even enable ?cool? features like proximity alerts and social logins (and we all like ?cool?).
The right enterprise-class API gateway can enable you to get your digital projects in production quickly and safely by:
- Reducing the attack surface. Expose only what?s needed and require all API traffic to go through the API gateway.
- Using a secure transport (i.e. SSL/TLS) to protect data in transit.
- Implementing strong policies at the gateway to ensure that threats are mitigated.
- Controlling access via a strong identity and access management (IAM) solution, and implement Single Sign-On (SSO) where it makes sense (thus also improving customer experience).
- Enforcing a strict interface (i.e. validate protocol, resource, method, parameters, schema).
- Validating, and optionally encode, input, as well as output, parameter values.
- Rate limiting (to not exceed capacity anywhere).
- Providing API monitoring (log and audit).
Will this give you 100 percent coverage, keep the bad guys away, and bring peace on earth? Well, not 100 percent. But it does provide a strong API security model for any digital transformation. And the goal here is to make it very difficult for attackers to get in ? the premise being that if you make it difficult, they?ll move on to easier targets. As we saw at the beginning of this blog, you don?t want to be that easier target.
