API usage in application development has become a standard.
APIs are a critical aspect of business delivery in the digital world – they connect mobile applications, the Internet of Things, and provide the structure that links internal business processes.
How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%
Considering the pervasiveness and importance of APIs, it’s obvious that we should secure them– after all, we don’t want hackers to use an API to access our business information housed in mobile apps, devices in your home, or processes that could cripple your business if they were compromised.
According to Gartner, by 2022, API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications.
In this article we’ll discuss top API security threats and API protection best practices.
APIs and modern web applications
APIs allow developers to create an open architecture for sharing functionality and data between applications.
APIs give client-side developers—both legitimate developers and potential system crackers—much more finely grained access into an application than a typical web app. This is because the granularity boundary for calls to back-end tiers moves from relatively secure internal tiers (those that reside safely in a DMZ) all the way out to the client application residing on the Internet.
The problem with APIs is that they often provide a roadmap describing the underlying implementation of an application—details that would otherwise be buried under layers of web app functionality.
This can give hackers valuable clues that could lead to attack vectors they might otherwise overlook. APIs tend to be extremely clear and self-documenting at their best, providing insight into internal objects and even internal database structure—all valuable intelligence for hackers. But increased visibility isn’t the only risk APIs introduce. Increasing the number of potential calls also increases the attack surface, meaning that a hacker simply has more to exploit.
Top API security threats
DoS attacks – In a Denial of Service (DoS) attack, the attacker in most cases pushes enormous messages requesting the server or network to establish requests consisting of invalid return addresses. The attack is capable of rendering an API into a non-functional situation if the appropriate security precautions are not adopted. In recent times, whether your API is exposed or not, it could possibly be accessible by other people.
As these API DoS attacks become more common, and as organizations increasingly rely on APIs for their business needs, security professionals should proactively plan to deal with such attacks. Even if an API key (or access token) used for application authentication is disabled, a key can easily be reacquired through a standard browser request. Therefore, invalidating a current access token is not a long-term solution. If a DoS attack is traced back to a specific IP address, then blacklisting that IP address isn’t a long-term solution either, because the attacker can easily acquire a new one.
To prevent a massive amount of API requests that can cause a DDoS attack or other misuses of the API service, apply a limit to the number of requests in a given time interval for each API (also called spike arrest). When the rate is exceeded, block access from the API key at least temporarily, and return the 429 (too many requests) HTTP error code.
Man-In-The-Middle attacks
It’s when an attacker secretly altering, intercepting or relaying communications between two interacting systems and intercept the private and confidential data pass between them. MITM attacks occur in two stages: interception and decryption.
Insecure endpoints
API endpoints are often overlooked from a security standpoint. They live on for a long time after deployment, which makes developers and sysadmins less inclined to tinker with for fear of breaking legacy systems relying on those APIs (think enterprises, banks, etc). Endpoint hardening measures (hashes, key signing, shared secrets to name a few) are, therefore, easier to incorporate at the early stages of API development.
API protection best practices
Focus on authorization and authentication on the front end
APIs are connected to other software. Securing the code properly requires that developers take a multi-pronged approach. This starts with solid authentication, which is the process of checking to see if a person is who they say they are.
Enterprises have been moving away from simple password systems to multistep authentication with a growing emphasis on biometric solutions like fingerprints. Once the person is authenticated, they need to pass an authorization check and gain access to different types of information.
For instance, few employees need access to payroll data, but everyone should be able to read the company president’s blog. Finally, an enterprise needs to make sure that corporate data is kept safe. Increasingly, businesses encrypt information from inception to deletion. Previously, data was encrypted mainly when moving from place to place on the network. With encryption, if the bad guys somehow get in, ideally, they cannot see anything of value.
Use Quotas and Throttling
If you produce an API that is used by a mobile application or particularly rich web client, then you will likely understand the user behavior of those applications clients. If a typical user calls the API once or twice per minute, it’s unlikely that you will encounter several-thousand requests per second at any given time.
A behavioral change such as this is an indication that your API is being misused. Throttling also protects APIs from Denials of Service and from spikes. It’s possible to implement sophisticated throttling rules to redirect overflows of traffic to backup APIs to mitigate these issues.
Turn on SSL everywhere
Make SSL/TLS the rule for all APIs. In the 21st century, SSL isn’t a luxury; it is a basic requirement. Adding SSL/TLS—and applying this correctly—is an effective defense against the risk of man-in-the-middle attacks.
SSL/TLS provides integrity on all data exchanged between a client and a server, including important access tokens such as those used in OAuth. It optionally provides client-side authentication using certificates, which is important in many environments
Don’t rely on traditional solutions
Traditional solutions work based on signatures or known patterns and can only protect you from common, known attacks like SQL injection (SQLi), cross-site scripting (XSS), and cross-site request forgery (CSRF). These solutions can’t detect vulnerabilities in the unique logic of your APIs. On top of that, these “old attacks”, once popular, have become less common because of modern application architectures and development best practices. A few examples:
- Cross-Site Request Forgery (CSRF) and some reflected Cross Site Scripting (XSS) attacks can’t be exploited in many modern web applications since they don’t use cookie based authentication.
- SQL injections (SQLi) are becoming less common because application frameworks provide built-in solutions for developers to avoid them.
Attackers haven’t given up and have also evolved to keep up with the times. Your APIs are complex and unique and attackers take advantage of this by looking for vulnerabilities in the unique logic. These are things that can’t be identified by a signature and are too devious to be addressed with good development practices. Your API protection solution must be able to understand the unique API logic at a granular level to identify potential vulnerabilities and stop attacks.
Conclusion
API protection is a complex topic, and since APIs are an integral part of modern software development, this issue has to be approached carefully. If you’re not sure about what you have to do to protect your APIs, contact us today to help you out with your performance and security needs.
