Remember the infamous Cambridge Analytica Gate? That is probably the most known case of APIs security breach. But that’s not a rare case, API related security concerns are real threats and we have significant vulnerability cases every few days, some well known, some limited in coverage.
With more and more integrated, data heavy and complex applications coming up and with the pressure of time to market, increased usage and adaptation of API based and microservices based architecture is inevitable.
However with so many small components integrated, free Public APIs , social profile logins, security risks are for real. That topped up with need for speedy development, it’s a ticking time bomb which explodes often.
The associated risks, implication are immense. With usage volume of paid & free Public APIs skyrocketing, API security threats need to be taken very seriously. Let’s review how one can make sure that APIs are secured, both while exposing and consuming.
OAuth is Must
The biggest vulnerability has been around access control for authorization and authentication. OAuth, token based authorization framework has grown exponentially popular addressing this as it allows token based authorization to third parties while safeguarding real user credentials. It’s a must have for any applications these days.
It’s a preventive measure which needs to be modelled continuously with time. It’s a structured way to identify and evaluate risks, mostly in automated and controlled fashion. Assess, mitigation and prevention cycle is what needs to be done periodically.
This should be no brainer. All sensitive and identifiable data should be encrypted with trusted methods such as TLS (Transport Layer Security). Post authorized user signature validation only, data modification and decryption should be allowed. This can be done via Tokenization.
This concept ensures that each identity has access tokens created around them while the real, sensitive information remains behind walls. It’s used not just for user identities but for objects, services access and everything else which needs authorization.
It’s a basic adaptation in current times. Trusted gateways allow traffic authentications, control and analysis. One needs to enforeceit for all sorts of free Public APIs communications to and fro.
Adaptation of Zero-Trust Policy
There is nothing called “always trusted” in this approach. ZTM (Zero Trust Model) ensures what’s inside is trusted and what’s outside is not. The idea is to focus on specific users, resources and not on location.
Parameter exchange happens all the time when we use APIs. Parameters types and their value range are always well defined. Hence incoming parameters data validation can ensure no harmful data is authorized. There is a strict schema against which permissible inputs are validated.
Usage of service Mesh
Similar to API gateways method, Service Mesh adds a control and management layer while handling service requests between different components. Apart from security this architecture assists with request processing optimization as well. It also ensures API management moving to the service communication layer.
Things Will Become More Scary
The more cloud based, microservices based, highly integrated and data heavy applications are made, the production and consumption of APIs will skyrocket and with that the security concern is only going to get bigger and more critical. The above suggested approach does not guarantee 100% security from threats but their adaptation will definitely ensure protection against the overwhelming majority of threats.