How to Secure APIs – 10 Best Practices to Follow

APIs (application programming interfaces) are a foundation for modern software development. They simplify the development process by providing a wealth of functionality and interoperability for programmers to use as they build their products. They save time and resources by eliminating the need to develop existing functions from scratch.  

However, over the years, malicious actors have found many ways to access and steal data from websites, servers, and other infrastructure through APIs. An incorrectly implemented, misconfigured, or forgotten API endpoint (see Zombie/Rogue APIs) can leave your entire infrastructure vulnerable to cyberattacks. Many APIs manage sensitive data, including personally identifiable information (PII) and intellectual property (IP) information, which can make them especially lucrative targets for attackers.  

No company is immune to API threats. Even industry giants such as Google, Instagram, Clubhouse, and British Airways have experienced API breaches. The high-stakes nature of API breaches makes it crucial for businesses to learn how to secure APIs. Let’s look at the common risks and how to secure APIs against them.

What Are the Common API Risks? 

Risks associated with APIs are data breaches exposing sensitive user data, unauthorized access that might allow for a wide range of bad outcomes depending on what those breached systems might control. APIs that manage sensitive information are more likely to be targeted by exploitation attempts. There are multiple ways for attackers to exploit an API, some of the most common include:  

1. Broken Object Level Authorization (BOLA) Exploitation 

Object-level authorization is a control mechanism implemented in APIs to ensure that users only have access to objects they are authorized to access. There are a variety of ways to control access including session tokens, session keys, even time-based parameters and more dynamic controls beyond that for complex environments.  
 
Every API whose endpoints receive an object ID and perform an action on the object should implement object-level authorization. If the object-level authorization is broken, attackers can manipulate the ID of an object sent within the API request at the endpoint to gain access to sensitive data that they should not have access to. 

2. Denial of Service, DDoS, and Other Bot Attacks 

Denial of service (DoS) attacks occur when an attacker disrupts or attempts to disrupt the normal flow of traffic to a server or network by creating a massive influx of requests that inevitably overwhelm the server’s resources. In distributed DoS (DDoS) attacks, the attackers utilize a large number (potentially millions!) compromised devices, often across a variety of geographies, to channel requests to the target. These compromised devices are called bots, and the connection between multiple bots is called a botnet.  

In a DDoS attack, each bot sends a request to the server address as a normal system user would. But since these requests come at the same time and are often pointed toward one target, they overwhelm the target’s server resources, making the service, website, or network abnormally slow and, in some cases, unavailable. 

Besides slow connection speeds, the following can be telltale signs that your website might be under a DDoS attack: 

• Large amounts of traffic coming from one IP address or multiple IP addresses within one range 
• Large amounts of traffic from entities with similar profile characteristics, such as web browser versions, device type, and perhaps but not always similar geographies 
• An unprecedented surge of requests to one page or endpoint 
• Suspicious surges in traffic at specific intervals or during odd hours of the day, especially during holidays and weekends 

While they might not expose your data, DDoS attacks can render your platform unusable to your users – which often translates to costly uptime SLA violations and lost revenue. The most common DDoS attacks are application-layer attacks, protocol attacks, and volumetric attacks against websites or API endpoints. 

However, it’s important to note that attacks by malicious bots are taking more forms than ever before. For example, in a credential stuffing attack, login pages experience a surge of requests from a bot automatically cycling through a database of know login information to see if they can gain access. We’re also seeing attackers learn and evolve behavior to both evade traditional simple detection rules and to distract defences I.e., using a DDoS attack on a specific site to preoccupy the security team while exploiting a separate vulnerability elsewhere that gets lost in the noise. 

3. Pagination Attacks 

Pagination is the practice of separating information into different pages. It is common for APIs to provide users with a list of entities. The client usually filters and paginates through that list and returns a limited number of entities – only the required bits. In a pagination attack, the attacker bypasses those limits to expose large numbers of sensitive information stored therein. 

4. Insecure API Key Generation 

Most developers use API keys to secure APIs. An API key is a unique identifier that helps track and protect the API in case of a breach. Through an API key, system managers can identify suspicious behavior and block access to the user. Attackers, knowing this, can use ingenious ways to generate API keys and then use them to perform DDoS attacks, like using compromised devices as attack sources. 

5. Incorrect Server Security 

Server security involves the measures taken to protect the data held by a server. One of the most effective ways to secure a server is by using server security certificates such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS). These protocols encrypt sensitive data by scrambling it. If the information stored or sent by a server is not secured properly, attackers can gain access to API keys and orchestrate a DOS attack. 

6. Injection Attacks 

API breaches often arise from injection attacks. Injection happens when an attacker feeds an API with malicious code or commands. Once in the system, that information can help them orchestrate a DOS attack or take over the server hosting the API. Injection usually happens when the client-supplied data is not filtered, validated, and sanitized. 

Best Practices for Securing APIs 

Securing APIs ensures the integrity of your site and servers. The type of data managed by the API usually dictates the security measures to put in place. Below are best practices on how to protect APIs: 

1. Inventory APIs 

Your organization could have numerous publicly shared APIs. It is not possible to secure the APIs if you are not aware of how many there are. It’s always good practice to inventory all your APIs and put a plan in place to manage them. Failure to do so might leave security gaps in your infrastructure. 

2. Employ Robust API Access Control 

Controlling authentication and authorization is one of the best ways to control access to an API. While there are many ways to authenticate an API, the most recommended is through OAuth. OAuth is a token-based authentication framework that allows third-party services to access information without exposing the user’s credentials. 

For more control, you should configure tokens to expire after a specific period, for example, after 24 hours. That way, the API will have to re-authenticate the user, and in the event of a breach, the attackers will only have a limited window into your resources. 

3. Employ a Web Application Firewall (WAF) 

A web application firewall is an intermediary between the Internet and the server. WAFs come in many varieties ranging from inexpensive, simple defenses to robust, enterprise-grade protection. Truly modern WAFs, known as Web Application and API Protection platforms can provide protection via in-line blocking for all your layer 7 traffic, across web applications and APIs in any infrastructure, cloud to legacy on-prem.  

WAFs should provide instant protection from attacks by filtering, monitoring, detecting and automatically blocking malicious traffic from reaching the server. WAFs also come in handy in the event of a DDOS attack, allowing you to change policies promptly should you need to employ rate limiting. They should also have the ability to identify, track, and block suspicious use of an API. 
 
Consider carefully the following when selecting a WAF: 

• What threats will this protect us from? 
• Can I run this in full blocking mode? (Run a proof-of-concept!) 
• How much work will this be to maintain through deployment, updates, and custom ruling? 
• Is the platform available as a managed service, is support robust? 
• Can this protect all the traffic I need it to across applications and APIs? 

4. Use Rate Limiting 

Rate limiting denies subsequent requests for information beyond a certain threshold. By limiting the method and frequency of API calls, you can stop overbearing traffic and protect your site from DDoS attacks. 

5. Identify Vulnerabilities 

To get better at securing APIs, developers should think like an attacker and understand which parts of the API’s lifecycle are vulnerable to attacks. They should also structure the API in such a way that they can detect and thwart attacks. 

6. Prioritize API Security, Seriously 

Organizations should treat their APIs like software artifacts. This means planning, threat modeling, developing, testing, securing, and staging it like they would with an application. 

7. TLS Encryption 

You should encrypt all data held and managed by a server, whether at rest or in transit. Data at rest is often encrypted using symmetric encryption while in transit, data is encrypted using TLS, the successor to SSL, which is now obsolete. TLS ensures that attackers cannot see or tamper with the data and that communication only comes from genuine sites. 

7. Employ a Zero-Trust Privilege Model 

Traditionally, networks contained a perimeter that had elements inside and outside. The elements inside the perimeter were ‘trusted,’ and those outside were not. While that setup protects the network from external threats, it leaves it vulnerable to insider attacks.  

To mitigate this, all users and applications must be authenticated and authorized. In simpler terms, employ zero trust apis. Additionally, since the vulnerability of an API is correspondent to the level of access other parties have, the API should provide the least possible privileges needed for a user or service to perform its roles. 

8. Don’t Expose More Information Than Necessary 

Always ensure that an API only returns the information required to fulfill the client’s functions and filters the rest out at the endpoint. Some APIs leave data filtering roles to the user interface, which ends up revealing more information than is necessary. In addition, think about other ways to simplify your API usage to narrow attack vectors. 

9. Validate Client-Sourced Data 

Always validate, filter, and sanitize input from an endpoint before passing it through to the endpoint. This can protect your website or infrastructure from attacks such as SQL injection.