Shifting security left means that API security can’t be left only to security teams. Developers need to be on top of potential vulnerabilities and remediate them as they develop. Building security into DevOps means we need to be thinking about how to deliver secure, high-quality code at velocity. Having some basic API security info under your belt will help.
APIs serve as a fundamental part of modern software development across industries. A recent survey of developers showed that 90.5% of developers expect to use APIs more or as much as in 2021, while only 3.8% of developers think they will use fewer APIs in 2022. The three industries with the highest percentage of developers who expect to rely on APIs more in 2022 than 2021 are healthcare (71%), technology (69%), and financial services (68%).
APIs pose an ongoing security concern because they are the gateway to data and to systems. In 2021, an undergrad at Rochester Institute of Technology who was searching for better student loan terms discovered an Experian breach that allowed him, or anyone, to look up private credit score information for tens of millions of Americans. When examining the code behind the lookup page, he saw that it invoked an Experian API that allowed lenders to automate queries for FICO credit scores. But because it was publicly exposed, anyone could use it without the proper authorization to look up credit scores.
You might have seen the news reports about how Ukrainian forces remotely “bricked” John Deere tractors stolen by Russian forces. That the machines could be disabled remotely using GPS intrigued some security researchers, who discovered that anyone who signed up for a developer account and who possessed the VIN number of a piece of Deere equipment could access that equipment remotely. This poses a serious risk to the American food supply, as Synopsys security advocate Taylor Armerding noted in a recent Medium article.
In a world where every business in every sector—from finance to agricultural machinery—is a software business, it’s imperative that developers have some knowledge of API security.
So how can you ensure that the APIs you use and produce are secure?
This list of API-specific top 10 vulnerabilities released by the OWASP organization in 2019 is not brand new, but let’s take another look at it. Just as the OWASP Top 10 standardizes vulnerability information for developers across web application security, this specialized list represents a broad consensus about the most critical API security risks to web applications. Let’s take a look at each one and see why it poses a problem.
Object-level authorization is an access control mechanism that is usually implemented at the code level to validate that a user can access only objects that they should have access to. Every API endpoint should implement object-level authorization checks to validate that the logged-in user is authorized to perform the requested action on the requested object.
When authentication mechanisms are implemented incorrectly, they can allow attackers to assume other user’s identities. Authentication endpoints and flows are assets that need to be protected, including your forgot password / reset password systems. When password reset protocols are an afterthought, they form a rich attack surface for broken user authentication attacks.
Developers tend to expose all object properties by default, relying on clients to perform data filtering before displaying to the user. Malicious actors take advantage of this weakness by sniffing the traffic to analyze the API responses, looking for sensitive data exposure that should not be returned to the user.
Too often APIs do not impose any restrictions on the size or number of resources that can be requested by the client or user. API requests consume resources such as network, CPU, memory, and storage. Not only can this impact the API server performance, leading to denial of service (DoS), but it also leaves the door open to authentication attacks such as brute force.
Authorization flaws can be caused by overly complex access control policies with different hierarchies, groups, and roles, and by an unclear separation between administrative and regular functions. Malicious actors exploit this flaw by sending legitimate API calls to API endpoints to which they should not have access, in order to access unauthorized functionality. Administrative functions are key targets for this type of attack.
Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. Since APIs expose the underlying implementation of the application along with property names, attackers can use this methodology to update or overwrite sensitive object properties that developers never intended to expose. Exploitation may lead to privilege escalation, data tampering, bypass of security mechanisms, and more.
Security misconfiguration can happen at any level of an API stack, from the network level to the application level. Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. Security misconfigurations can expose sensitive user data as well as system details that may lead to full server compromise.
Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Injection can lead to information disclosure and data loss. It can also lead to DoS or complete host takeover. This is why injection is listed as the third-most-critical security issue in the general OWASP Top 10.
Old API versions are usually unpatched. This makes them an easy way to compromise systems without having to fight state-of-the-art security mechanisms, which might be in place to protect the more-recent API versions. Attackers can gain access to sensitive data or even take over the server through old, unpatched API versions connected to the same database.
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, or extract or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, and they are typically detected by external parties rather than internal processes or monitoring. Lack of visibility into ongoing malicious activities gives attackers have plenty of time to fully compromise systems. Read about our logging and monitoring best practices for more info.
It’s no mistake that over half of the OWASP API Security Top 10 list is related to authentication and authorization. These failures are the most common means by which API systems are hacked.
It’s important to remember that authentication and authorization are two separate processes. Authentication is the process of verifying who a user is; authorization is the process of verifying what they have access to.
Getting API authentication right is crucial because the API relies on the user’s authentication to decide which authorization privileges to grant. One thing to keep in mind when setting API authorization protocols is that because clients are machines, you can ask for authentication much more often than you can of human users (who grow impatient).