Do You Really Need API Security? A Complete Guide

An API, which stands for Application Programming Interface, is a set of rules and protocols that enables two different software components—such as two containers, or a mobile app and its backend system—to communicate with one another in order to share data and functionalities. As well as enabling this communication, APIs also govern it, controlling the types of requests that different programs exchange, how they’re made, and which data formats they’re allowed to use.

Today, APIs are everywhere: developers use them to gain access to the functionality of other applications, and organizations use them to share data with customers and partners. They enable payment processing, video conferencing, and smart devices—they even connect you to your Uber driver when you book a ride. In fact, 99% of organizations have already embraced APIs and 83% of all internet traffic runs through APIs!

The proliferation of APIs makes them an attractive target for cybercriminals. And unfortunately, while many organizations impose strict verification checks on human access requests (e.g. by using multi-factor authentication), the same can’t be said of API access—many APIs are only required to present a single, static key before being granted automatic access to sensitive data, resources, and application logic. 

But how likely is it that unsecure APIs will actually be targeted by a threat actor? And do you really need API security to prevent that from happening, rather than relying on a traditional web application firewall?

That’s what we’re here to answer.

What Are The Risks Of Unsecure APIs?

Around 84% of organizations rely on either bare API keys or basic shared secrets for API authentication. This means that their APIs are authenticated using a static credential, like a permanent password that’s never changed or monitored—making it very easy for threat actors to crack or steal. Unfortunately, threat actors arecracking and stealing these credentials. And it’s having a huge impact on businesses globally.

The total annual figure for API-related cyber losses globally is estimated between USD 35 and 87 billion; that means API-related losses account for up to 6% of all global cybersecurity losses annually. Among large organizations (with over USD 100 bn in revenue), up to 18% of cyber incidents are likely to be API-related. But while larger enterprises tend to be the most common target due to their heavier reliance on APIs, they aren’t the only target; 4-5% of cyber incidents are API-related among smaller companies with revenues below USD 500 million.

And that’s only the financial impact. API-related breaches also enable attackers to steal sensitive data and cause great reputational damage, as was seen in the following high-profile attacks in recent years: 

• T-Mobile: In 2023, a threat actor the obtained information of 37 million of the company’s customers by exploiting an ABI vulnerability. 
• Twitter: In 2022, a threat actor leveraged a public API flaw to access and leak account data. 
• Optus: In 2022, a threat actor breached an unprotected and publicly exposed API, using it to expose the details of 11 million customers. 
• Experian: In 2021, the credit scores of almost everyone in the US were exposed via an unprotected API, after a security expert found that they could access any user’s credit score with no authentication. 

So, it’s clear that unsecure APIs are dangerous. But how exactly are threat actors exploiting them?

The Most Common API Security Risks

In 2023, the Open Web Application Security Project (OWASP) published an updated list of the top 10 API security risks affecting modern web applications. All of these vulnerabilities are classified as either common or widespread, and are easy or average for a threat actor to exploit:

1. Broken object level authorization: This vulnerability enables attackers to gain unauthorized access to other users’ objects, which they can use to manipulate or steal data, or carry out a full account takeover. 
2. Broken authentication: This vulnerability enables attackers to gain complete control of other users’ accounts, enabling them to view the user’s personal data and perform actions on their behalf. 
3. Broken object property level authorization: This vulnerability gives attackers access to private or sensitive object properties, typically enabling them to steal or corrupt data and sometimes enabling them to carry out a partial or full account takeover. 
4. Unrestricted resource consumption: This vulnerability can lead to Denial of Service (DoS), as well as an increase in operational costs (e.g., due to higher CPU and cloud storage demands). 
5. Broken function level authorization: This vulnerability enables attackers to access unauthorized functionality, such as administrative functions. This in turn can allow them to steal or corrupt data, or disrupt services. 
6. Unrestricted access to sensitive business flows: Unlike many of the others on this list, this vulnerability doesn’t typically have a big technical impact. Instead, it enables attackers to cause business disruption, e.g., by preventing users from being able to purchase a product. 
7. Server side request forgery: This vulnerability enables attackers to bypass firewalls or other security processes, enumerate internal services, and access data. It can also enable attackers to carry out DoS attacks or use the server as a proxy to hide further malicious activities.
8. Security misconfiguration: This vulnerability encompasses issues such as unpatched flaws, services running with insecure configurations, and unprotected files—all of which attackers can use to access sensitive user data, or even system details that enable them to compromise an entire server. 
9. Improper inventory management: This vulnerability enables attackers to access sensitive data and administrative functions, or even take over the server. 
10. Unsafe consumption of APIs: The impact of this vulnerability depends on what the API does with pulled data, but it typically enables attackers to access sensitive data and carry out injection or DoS attacks. 

Why Don’t Traditional AppSec Methods Work For APIs? 

If you already have a Web Application Firewall (WAF) in place, you may be thinking that you don’t need to worry about any of these risks. But unfortunately, these tools can’t provide complete protection against API attacks. 

WAFs are deployed at the perimeter and inspect HTTP traffic for known malicious traffic patterns. If they spot these patterns, they block the traffic. This worked well when most developers were working with monolith applications hosted by individual web servers, but it isn’t enough to secure modern applications running on highly distributed, cloud-native, and perimeter-less architectures. These apps consume input from a broader range of sources; not only standard web requests, but also mobile device API calls, cloud events, cloud storage, device telemetry communication, and so on. So, inspecting input at the perimeter isn’t enough to identify malicious activity; you need a solution that continuously monitors all external and internal API endpoints. 

On top of that, traditional WAFs only identify known attacks; they can’t block attacks using unknown attack patterns.

How Does Modern API Security Work?

Today, API security solutions use a combination of techniques to secure APIs against misuse, exploitation, and unauthorized access. These typically include: 

1. Continuous monitoring: The tool continuously monitors all API interactions, using a combination of signature-based detection and ML-driven anomaly detection to identify both known and unknown threats. 
2. Input validation: The tool validates all API inputs to help block malicious payloads and injections attacks.
3. Rate limiting and throttling: The tool controls the number of requests being sent to and from each API, preventing DDoS attacks, brute force attacks, and API scraping. 
4. Authentication and authorization: The tool verifies the identity of any systems or users interacting with the API, ensuring only authenticated entities can access specific resources and systems. 
5. Access controls: The tool implements least-privileged and role-based access controls to further prevent unauthorized access and limit the amount of damage an attacker can do if they do compromise an API.

When they discover any vulnerabilities or flaws, the best API security tools alert you to those issues, sometimes offering automated or guided remediation to help you resolve them more quickly and effectively.

Diving Deeper: API Security For SOAP, REST, And GraphQL

While the above is how most API security tools protect APIs, there are some more specific security considerations you should be aware of, depending on the type of APIs you’re using. 

There are three common API architecture patterns: SOAP, REST, and GraphQL APIs. 

SOAP stands for Simple Object Access Protocol. These APIs used to be the most prominent, and they’re used for exchanging structured data while implementing web services. SOAP APIs are typically secured using transport layer security and message-level security. They also adhere to the Web Services (WS) specifications, which ensure security for all web services. 

REST stands for REpresentational State Transfer. REST APIs rely on JSON data transfer and the HTTP/S transfer protocol, which makes them much simpler to develop than other types of APIs. Because of this, most modern web APIs today are REST APIs. However, REST APIs don’t have the inherent, in-built security that SOAP APIs do; you need to secure them by building and implementing them correctly, e.g., by deploying them behind an API gateway and alongside an API security solution. 

GraphQL APIs are open source, and they’re becoming increasingly popular amongst developers using them to make specific data requests from single or multiple sources. To secure GraphQL APIs, we recommend using throttling and setting a maximum query depth and query timeout. This will help prevent the server from being overloaded by large or complex requests and accidentally executing malicious queries as a result. 

Our Recommendations: API Security Best Practices 

So, do you really need API security?

The bottom line is “yes.” Implementing the right API security processes can help you block API-based attacks, prevent data breaches, improve the performance of your applications, and improve customer trust. 

As for how to do that, we recommend following these best practices:

1. Incorporate API security into every stage of your SDLC—from the initial design, right up until you deploy your product. 
2. Regularly review your API inventory to make sure you’re aware of any new or newly exposed APIs, along with their risk level (i.e., the amount of sensitive data they’re exposed to, whether they’re exposed to the internet, etc.). 
3. Continuously monitor your API traffic for anomalies, bugs, and required updates, and address these as required. 
4. Make sure that only authorized, authenticated users can access the API. To take this a step further, you should implement the principle of least privilege, so APIs and apps are only granted the minimum permissions they need, for the minimum amount of time they need them, to be able to do their job. For third-party integrations, make sure you restrict them to only the most essential permissions. 
5. Never hard-code API keys into your application. Instead, store them in environment variables, a secure vault, or some other place outside of your application’s source code.
6. Rotate API keys that are currently in use periodically and delete ones that are no longer needed. This will prevent old API keys from being compromised.
7. Implement rate limiting on your APIs to restrict the number of requests that can be made of that API within a certain period. This will help prevent brute-force attacks. 
8. Make sure all API requests and responses are made using HTTPS. This will help protect sensitive data against unauthorized viewing. 
9. Use API security testing tools, SAST, and/or DAST to identify unsecure code and runtime vulnerabilities.
10. Assess the security of any third-party APIs before integrating them into your own project. Software Composition Analysis (SCA) tools can help you spot risks that crop up amongst any third-party libraries you’re using.

And our final top tip: implementing a strong API security tool will help you to achieve a lot of these practices much more easily than trying to keep on top of them manually!