The APIWorld conference came to end last week. This was the first public preview of our platform! We had a blast talking to many attendees and presenting at the event. This also gave us the opportunity to address a few common questions relative to API security and our product.
1. I have seen 3 vendors on the conference floor, they all define API Security differently!
Glad you asked:)
API security as illustrated by the image below covers a lot of different aspects and it’s critical to look at API security in an holistic way.
As a provider, you need to:
- Secure the infrastructure (OS configuration + network configuration)
- Properly configure your servers (for example, enforce TLS 1.2, remove certain cipher suites, eventually enforce mutual SSL, use security headers, use secure cookies, use latest versions of frameworks, etc.)
- Defend against attacks by validating data: this includes JSON/XML validation, attacks detection, OAuth/OpenID connect attacks protection.
- Ensure API payloads (messages) are encrypted and/or signed depending on data and operations sensitivity.
- You must authenticate users.
- You must authorize users (and no, OAuth2 scopes might not be enough)
- You may have to implement non-repudiation for critical transactions
- You must audit everything happening, at system level and at transaction level. This is critical for security forensics.
And you need to adapt the settings for all of the above depending on the API you want to secure.
Yes, we know. It’s complicated, but that why we created our company in the first place , so that applying security would be easier and could be automated !
2. I already have a WAF (Web App Firewall). Can I use that to protect my APIs ?
WAF were built for a specific purpose: protect web applications. Web applications architecture has evolved over the past years to use APIs as their back-ends (instead of traditional application servers). Basically, APIs are now the entry point into your enterprise, exposing data and processes from your core enterprise applications. The other major change is the externalisation of some of this data and processes, to public cloud and SaaS applications. An application today is typically mashing up 5 to 10 APIs accessing internal and external systems.
While WAFs are capable of filtering HTTP traffic and understand the protocol, they do not understand APIs. In order to properly protect APIs, you need to understand API specific protocols and standards. Using a WAF to protect APIs implies defining lots of specific rules to avoid false positives, a manual process which makes it hard to keep up with the constant API changes. If you are using JOSE for message encryption and signatures, your WAF will most likely be incapable of decrypting the contents to search for attacks inside the payload nor verify signatures. Similarly, it will not be able to understand/intercept OAuth or OpenID Connect attacksĀ specific to the protocol, for example by enforcing recommendations as per the OAuth2 threats and security considerations RFC.
Of course, WAFs still have their place for protecting web applications!
3. Why is your API firewall better at blocking API attacks ?
An API can be described very precisely using OpenAPI (a.k.a Swagger) – OpenAPI serves as the contract between the API provider and the API consumer. If your OpenAPI describes all the data coming in and out, including string patterns, bounded values for fields, mandatory headers and query params, payload formats, many attacks will be blocked by the engine as they will not match the description. Still, a false positive can happen, and we have means to let you specify that. But most of issues will be blocked by the white list alone. Of course, we also apply a black list to further analyze the traffic, after the white list has been applied.
4. I have an API gateway in place. Isn’t that enough to secure my APIs?
It depends on the API gateway you use and the features it offers, but most importantly it depends on how *you* configure it. You will have multiple policy building blocks to choose from and and you will need to combine them to do all the proper checks we mentioned in point 1. Can you do it? Yes. But:
- It will take you weeks of development and testing
- You have to maintain the setup for each individual API, which makes automation very difficult.
- Implementing this properly will imply understanding hundreds of pages of RFC.
You also need to implement a DevSecOps approach whereby security is available as-code and can be applied as part of the overall API lifecycle. APIs and applications are developed at a very fast rate and security cannot be left behind. Automation is the only way to making sure your APIs are tested properly , with security applied, each time they are re-deployed, across all environments ( from Dev through Production) as illustrated below.
The other key difference between what we do and how API gateways/API management solutions work is that we choose the rightĀ setup depending on your APIs, their risk level, and the type of clients that will consume them. For exemple, while OAuth2 supports 4 standard grant types, only one of them (authorization_code) is recommended when critical data needs to be accessed. Similarly an OpenID Connect hybrid flow is recommended for authentication. Check theĀ UK OpenBanking banking read-write security profileĀ for an example of the type of rules API developers and security teams would need to properly interpret and implement.
Our solution is totally compatible with existing API gateways. The recommendation is that you delegate all security validations to us and keep using your gateway for integration needs and for token management (e.g. as the OAuth and OpenID Connect Authorization Server).
5. My API requires an API key – Is that secure enough ?
Keys are just long strings which are meant to uniquely identify an application calling the APIs. Keys can be used for monitoring and usage tracking purposes, but do not authenticate the user. In other words you have no guarantee that the user calling now is the one you actually issued the key to. Think of it like an hotel key: I go to the front desk, show my passport, get my hotel key. I can then pass that key to anybody, they will still be able to open the room door. While the hotel will have a trace that this key was used, they have no idea by who, because no authentication happens in order to use the key.
API keys can easily be stolen if HTTPs traffic is not in place, and usually end up in application code, GitHub, and other accessible repositories. Yes, they are very easy to use, but also very easy to abuse!
This said, API keys do have a place for some APIs. With APIs, one size does not fit all. You need to adapt the security measures to the threat model. Evaluate the risk associated with your API, then apply proper security. If you are publishing the next award winning weather online service via APIs, a full-fledged authentication and authorization enforcement to access this API might be overkill. If you’re working in the finance industry on implementing the OpenBanking directives, that’s another story.
followed by : Ok then, I have OAuth. Isn’t that secure enough ?
Well, you’ve definitely have made some progress, but no, not yet. First of all, despite the name , OAuth is not about Authentication, it’s about delegated access to resources.Ā This implies that you still need an authentication layer: that’s the goal of OpenID Connect, an authentication layer built on top of OAuth.Ā Moreover, it’s a framework: it needs to be used properly depending on your needs. You need to choose wisely the grant types you will allow, depending on the client (what OAuth calls confidential vs. public client). See point 4.
We are looking forward to helping you secure your APIs in the coming months. The feedback we got at API World was very encouraging and we believe we are on the right track to get enterprises closer to properly secure their APIs in a standard, repeatable and reliable way.
