5 API Security Principles That Are Here to Stay
With APIs becoming the most frequent attack vector of cybercrimes, it's now more important than ever to stay on top of API security trends. This vigilance is only heightened as the API security landscape changes constantly with new threats and mitigations. Yet, while keeping up to date with recent trends is paramount, security professionals must not forget the important, tried, and tested strategies.
Below, I've outlined five API security principles that are here to stay.
1. Use a Gateway. Always, No Matter What.
APIs should always be put behind a gateway. This provides several benefits as API gateways centralize both security-related tasks and practical business-related functions. Standard API gateway features include rate limiting, blocking malicious clients, propper logging, path and headers rewriting, and gathering business metrics. These features can be applied to every request made to your API. Sounds great, doesn't it?
Without gateway controls, you would have to reinforce each endpoint with these features one-by-one. But, in the case of a serious security threat, what happens if you miss one? Not having an API gateway could easily lead to severe security gaps.
2. Only Issue Tokens With a Central OAuth Server
The central OAuth Server should always issue access or refresh tokens. This should not be processed by APIs or gateways, as it is not their job. But why?
Issuing tokens requires many complex processes to happen:
Authenticating the client
Authenticating the user
Authorizing the client
Signing the tokens
All these, in their turn, involve the usage of different data, such as client information or the preferred authentication mechanism. This could also include many keys used to sign the issued credentials if you use various entities to administer and sign tokens. Juggling all these can become a handful. Using a central OAuth Server is the way to go, now and beyond.
3. Follow the Best Practices of Using JWTs, Scopes, and Claims
This may sound like quite a generic statement, but following best practices is the ultimate best practice. Some of these best practices include:
Use JWTs internally.
Create and reuse libraries for JWT validation.
Use scopes for coarse-grained access control and claims for fine-grained access control.
Don't mix authentication methods.
Manage claims centrally.
Have multiple sets of eyes checking and auditing your APIs.
These best practices might change, but listening to your API community and implementing the established mechanisms will always be an excellent way to protect your APIs.
4. Trust No One and Adopt Zero Trust
Trust no one. Limit trust on incoming traffic to your APIs, use HTTPS, and verify incoming JWTs. These Zero-Trust Architecture (ZTA) guidelines will be with us in the years to come.
You can read about the ZTA approach in an earlier blog post.
5. Protect ALL APIs
With organizations adopting more and more complex architectures, the number of APIs used is also growing. However, it's always important to remember that all APIs should be protected, whether they are internal or external. Attacks might come from inside; attackers might discover your APIs when created for internal use and then published externally. The potential for attack is real, even if you come up with a complicated name for an endpoint. Just protect them all.
Do you agree with these five API security principles? If you have other thoughts or want to discuss, don't hesitate to get in touch.