API security is often discussed, yet often ignored part of the API design. API Architects/designers spend a lot of time discussing the latest security standards and protocols, yet sometimes they end up ignoring some very important security measures for APIs. Sometimes, we get too obsessed with the Authentication/Authorization bit, and we overlook some other security provisions like content-based security and so on. In most enterprises, there is an API gateway or API Management layer which takes care of security aspects when they expose APIs for wider consumption. This article focuses on the security measures which should be in place in the gateway layer. To be clear, the security requirements of APIs differ from domain to domain. For example, a Banking or financial API would have a lot stricter security requirements than a retail or telecom sector API. However, some security measures would remain the same regardless of the domain or sector of the enterprise. So, here are those security measures or policies as we often call them:1. Transport Layer Security (TLS)Let’s start with the most obvious thing, all the APIs should be available on TLS i.e., HTTPS:// URL. Having an HTTP URL (starting from HTTP://) is a big NO. There are several APIs available on the internet which are still on HTTP. Not having TLS enabled is like an open invitation to hackers for all kinds of attacks. Sometimes, enterprises don’t bother about setting on TLS for internal APIs as they are meant to be consumed from within their secured network. However, in the case of internal APIs, if someone can gain unauthorized access to your network, that person can easily listen to the API traffic if it’s on plain HTTP. So, regardless of the purpose and target consumers of an API, it should always be secured via TLS. You need to get a pair of private keys and certificate from a trusted Certification Authority (CA), store this on the API server keystore, and configure your API domain to use this keystore so that API endpoints are called using HTTPS:// URLs. As a recommendation, you need to have one-way TLS from the client to the API gateway layer and two-way TLS from the gateway to the backend systems host.2. Protection against Spikes in TrafficYou need to enable a feature on the API gateway which protects against sudden spikes in client requests. Backend systems would have certain limitations on the number of requests they can process within a time frame. If a client or a set of clients make too many requests, it might bring down the backend servers thus denying access to other legitimate consumers. Sometimes client systems might be doing some load tests which might result in too many API calls or sometimes it can be a deliberate DDoS attack from a hacker with bad intentions. In either case, having this security policy would make sure such spikes in API calls from clients are handled properly and backend servers remain up.3. Authentication, Authorization, and IdentityThis is the basic minimum requirement to protect your APIs against unauthorized access. Based on the type and use case of the APIs, one of the following mechanisms need to be applied:In case your APIs need end-user authentication and consent, they need to be protected by OAuth2 authorization code grant or OpenID Connect. These are the standard security framework for authorization and user identity. More on these can be found on the protocol pages –OAuth2andOpenID Connect.In scenarios where there is no User context or consent required and the consumer is either an internal trusted app or partner app, anOAuth2 client credentialsgrant should be used to secure APIs.If an API is catering to clients which cannot do OAuth2 token flows for some reason, then at leastAPI Keybased security should be applied so that client apps should be authenticated. The API key can be accepted in either the request header or query parameter.4. Protection Against Parser AttacksMost of the time, APIs accept JSON or XML payloads in the request. In such scenarios, an attacker can try to send input that would overwhelm parsers in the backend services. For example, an attacker can send an array instead of input string values, it can send too many garbage fields and values, it can send some very long values in some fields, etc. Such kinds of attackers are designed to overwhelm the parsers and break them. That would cause the servers to go down and induce DoS attacks. So, each API that expects JSON or XML payload should have some kind of schema or structure level validation to ensure parsers are safe.5. Preventing SQL, Script, and Other Injection AttacksSQL Injection, HTML Script Injection, Java Exception injection, and so many other code injection attacks are quite popular content-based attacks that hackers try and use to retrieve data that they are not supposed to. Most of the time, APIs do not have provisions to prevent such attacks leaving backend services vulnerable. APIs should have some common regular expressions configured which should be validated against incoming data. There are common Regex patterns available to match against data containing SQL, HTML, and other injection syntaxes. A generic validation should be performed on the incoming data for the same.6. Masking and Encrypting Sensitive DataAs a thumb rule, all the sensitive data must be either masked (i.e., replaced partially or fully with ***) or encrypted/ tokenized. Each country has its data protection laws. Data like credit card numbers, bank account numbers, national id numbers, etc. are considered sensitive personal information. There are already some standards like PCI, HIPAA, GDPR, and so on. API gateways need to make sure they are not logging any such data in plain text in either debug or system logs. Also, things like OAuth2 tokens, API keys should not be logged in plain text to avoid abuse.7. Data Signature VerificationsIt is very important to verify the integrity of the incoming data in the payload or query string. If there is some proxy server or intermediate system between the client and the API layer, there are chances of Man in the Middle (MITM) and other attacks which can temper with request data. In that way, data integrity might be compromised. To counter such issues, a signature of the request data can be sent in either a header or payload. These signatures could be generated by the client either using a shared key or a private key (of which the public key should be accessible to the server). The API gateway can then re-generate the signature based on incoming data and match if the newly generated signature is identical to what is there in the request. It is understood that having all the security would have an impact on performance. However, most of the API gateways are equipped with the security measures mentioned above and can do such validations in a very quick time. API gateways are an entry to your APIs and Services so consider them as the main gate to your house. The more it is secured, the more you can sleep peacefully.EnvelopeTwitterLinkedin

Subscribe to Our Newsletter

Stay updated on the latest in the API space