Top API Security Flaws

APIs have enabled an incredible proliferation of tools that we never imagined — they allow you to collaborate with developers outside your company or even see new inventions that combine tools from big providers like Google and Facebook to create entirely new experiences.

APIs are great, APIs are powerful, and APIs are quickly becoming the biggest security risk to modern enterprises. That very power of flexibility and adoption creates brand new opportunities to exploit holes, blind spots, expansive features, and, honestly, just a lack of understanding of what really goes on in an API.

Here are a few common flaws and ways to help mitigate them.

1. Identity is for Everyone

A common architecture is to protect the edge of your network — if the call comes from inside the house, you figure the call is from family, and would your family ever betray you? Unfortunately, the callers might be visitors, someone who snuck in the back door, or your crazy uncle having a breakdown.

When Service A calls to Service B, you still need authorization. If Service A is the child and Service B is a cookie jar, the Auth Service (Mom or Dad) should be able to stop the transaction. It doesn’t matter that Johnny is our little angel — sometimes Johnny acts up and needs to be told “no.”

We see this in software when a service inside your secure ecosystem is compromised and starts poking around. Like Uncle Eddie on New Year’s Eve, we need to keep an eye out for erratic behavior.

Mitigation: Provide authentication and authorization at the service level, not just at the edge of the network.

2. Bad Code Happens

Even in the best pipeline, bad code happens. It might be a back door a developer forgot to close, it might be a library that got hacked at the source and included in the deployment process, or it might just be an unexpected combination of tools creating a security hole you could drive a truck through.

The reality is that we can’t trust code, and when you bake your security into your code, your security is compromised along with your code. Your security should be clearly defined, but independent of the service itself. This means that all traffic should have rules for who is allowed to talk to whom.

Yes, this might mean that Service A tries to reach out to Service B and can’t because, hey, we didn’t know Service A needed to talk to Service B…But if we didn’t know that, then maybe we’re missing more.

Mitigation: Encapsulate every service with both ingress and egress rules and log everything.

3. Disabling Security for Performance

You know how all those safety features on new cars are distracting? You feel like you aren’t really driving anymore, so you start turning off the traction control, the collision alert, or the lane departure assist… Next thing you know, you don’t see the truck in the right lane, and you smash right into it.

Disabling security is so tempting, but so bad.

As we spread our services out into smaller and smaller microservices, the number of distributed calls can cause a lag. If we have to check security on each one of those by going off to an auth server, then we are exponentially dragged our performance down. We want to get rid of those bottlenecks, so we start disabling security. Next thing you know, your entire network is compromised.

Obviously, there are times that your security gets in the way, but the answer isn’t to turn off all the safeties — the answer is to find a better architecture that works.

Mitigation: Enforce security as close to the service – with as few round-trip callouts – as possible.

4. Chaotic API Structures

A consistent API structure means a predictable API structure. It’s hard to apply code injection rules if one endpoint uses path variables and another uses query parameters, and you keep expanding your exceptions until there really isn’t any enforcement left.

Unfortunately, most companies don’t adopt an API style until they have a mess of different services with different ways of doing the same thing. And when you get into the mess of different languages, different coding styles, and different physical architectures, the idea of managing that becomes increasingly complicated.

Mitigation: Apply contextual security at the service itself, avoiding blanket policies that are either too invasive or ineffective. Also, adopt an API Design Standard.

5. No Chain of Evidence

The first question when there’s a breach is, “What did they hit?” That is, where did it come from, \where did it go, and what did they get? The problem is that so many systems don’t track the thread — in a distributed world, we see that a service got compromised, but we don’t really know why or from where.

You end up playing a game of whack-a-mole, unaware that a compromised service touched other services, possibly compromising them as well. When Facebook was asked how many accounts were affected by a breach (in one of their many breaches), the answer was, “We’re not sure.”

Not only does this mean they can’t guarantee that the problem was fixed, but they also can’t guarantee that they understand the scope of the problem. APIs give us a wonderful, scalable, distributed world of services, but the net effect is the same — you have to be able to tag and track transactions through the ecosystem.

Mitigation: Add context and tracing to every transaction linking a full chain of evidence together for greater visibility and mitigation.

Are you ready to invest in better API security for your business? Contact Cloudentity today, and let us show you how we can help.