Why API Security is Crucial?

API is fundamental for any digital transformation, these days almost every organization is working towards their Cloud Journey and Microservice architecture. For practical purposes (PHI, SPI, Legal, etc.), it may be hard to move data in Cloud with one go but a gradual movement to push data in the Cloud environment is the most common approach. So, in order to unlock Cloud capabilities while Organization work towards Cloud adoption it automatically raises higher importance to API security, as most of the APIs needs to be exposed on to public Clouds. Also, even there is always a strong need to expose APIs on public domain specifically if you are dealing with direct customers.

Hackers like APIs as they present multiple ways to access data which can be used together in unintentional ways. In 2018 alone, insufficient API security was the cause of at least half a dozen high-profile data breaches. By 2022, Gartner estimates that APIs will be the vector used most frequently in attacks involving enterprise application data.

There are various security risks involved when you are dealing with Public Cloud and exposing API resources to the public. To keep the organization safe from any attacks it is very important everyone understands its side effect and what all precautions must be taken. These days due to the way organizations are structured or transformed as independent products or agile teams, a lot of responsibilities on independent teams or processes such as DevSecOps, while in past, security was responsible for network or security teams but now it is a “shared responsibility”.

Let’s look into various security risks and what can be done to mitigate or protect APIs:

API Parameters — one of the most common ways used by attackers is to temper data in API parameters (query and path params). It can also be used to reverse engineering API resources and retrieve data if these parameters are straightforward which can be guessed easily.

In order to save APIs from such attacks, try not to use predictable inputs like counts but use some random UUIDs by leveraging OSS libraries. At the code level, developers need to sanitize the inputs by utilizing ESAPI. Also, execute test cases focused on security like fuzz testing, command injection. Even for UIs, hidden fields need to be evaluated properly.

DDoS Attacks — DDoS stands for Distributed Denial of Service attack, it is typically performed by when a malicious actor attempts to disrupt regular traffic of a targeted server, network, API by flooding the traffic using BOTs. Typically, internet resources have a specific capacity to handle a number of requests originating by the end client and whenever any system is impacted by a DDoS attack then it brings down or slows the whole system which eventually impacts the ability to server normal expected traffic. Typically, Hackers use a “zombie” network to deliver a DDoS attack which is done using Bonet (combination of robot and network). A DDoS attack can also be either a volumetric attack, an application-layer attack (HTTP, HTTPS, DNS, or SMTP), and a Protocol attack (SYN flood, malformed packets).

The DDoS attack is typically protected by securing network infrastructure like Firewalls, VPNs, content filtering, load balancer, strong password security practices on regular basis. It is also recommended to utilize the cloud as it has more bandwidth to scale than a private network which will increase fault tolerance. It is interesting to see how Nextflix DDoS’d itself to help protect its system.

Session Cookie — A session cookie is a piece of data that is stored on the user’s machine to remember the state as a session identifier (SESSIONID) which is always read-only for the user that includes user id, password, timestamp, etc. The main attack which is caused is “Cookie Poisoning”, in this technique attackers gain unauthorized information about another user to steal the identity. Cookie Poisoning is also one of the types of parameter tampering where parameters are stored in the cookie. It also causes attacks like SQL injections, Cross-Site Scripting, Session Sniffing.

Some of the ways to prevent eavesdropping of the session cookie are to use HTTP, use a secure cookie flag, keep session-id long and random, regenerate the cookie after every login attempt, don’t accept session IDs from GET /POST, use anti-malware at client and server-side, delete cookies when session is logged out.

API Identity Tracking — In complex API eco-system like IoT and API layering strategy, systems are designed to communicate using API channels, and in many cases APIs authenticate themselves using the client certificates. Now, if a hacker gets control for any middle API endpoint then it is easy to orchestrate the sequence to steal the data.

To protect APIs from Identity tracking, we can utilize common techniques like penetration testing, TLS encryption, deploy strong AuthZ and AuthN systems at all layers, conduct automated security scans and monitoring.

MitM attacks — Man In the Middle (MitM) attack allows hackers to intercept communication between two APIs either by secretly eavesdropping or alter the in-between traffic. Computer scientists have been looking at ways to prevent threat actors tampering or eavesdropping on communications since the early 1980s. MitM attack includes SSL stripping, mirror Wi-Fi access points where malicious actors can monitor, collect or modify user’s information.

Like other attacks, users need to follow best practices like don’t use public networks while working on confidential items, utilize VPNs, use TLS or HTTPS protocols, utilize 2-factor auth, install intrusion detection systems, etc.

In conclusion, as far as API security is concerned, one statement fits here “Prevention is better than cure”. And, also, I must say (I don’t want to say) that API security may be worse in the future as the organization moves towards APIs exposure to the public. So, the only way to keep organizations safe is to follow best practices of API security like leverage OAuth, use tokens, encrypt the data, use throttling, utilize patterns like API Gateway, service mesh, validate parameters, and at last “adopt a zero-trust philosophy.”