Application Programming Interfaces (APIs) are a type of software interface that allows services to communicate with one another to leverage each other’s data and functionality without needing to see everything that is on the other end. They enable applications to talk to one another, such as when you use your Facebook account to login to another app. APIs are becoming more prevalent throughout our web and mobile applications as they are convenient and facilitate rapid development, but they can also pose a security risk if not properly implemented.
The Open Web Application Security Project (OWASP) is a nonprofit foundation dedicated to promoting software security. Since 2013 OWASP has produced a list of the top web application vulnerabilities, but in 2019 they branched out to create a list of top 10 API risks, the API Security Top 10 2019. This iteration remains the most current version of the list and can be used as a starting point for securing your APIs.
1. Broken Object-Level Authorization
Applications that do not correctly implement Object-Level Authentication can be vulnerable to object access attacks. These occur when an attacker manipulates an object ID specified within an API request to access things outside the scope of their initial permissions. The most effective mitigation tactic is implementing authorization checks at the API gateway to enforce access permissions. An additional measure that has proven effective is using unpredictable IDs like globally unique identifiers (GUIDs) and rate limiting to drastically reduce the impact of brute force style attack.
2. Broken User Authentication
APIs typically leverage tokens for authentication. If compromised, an attacker can masquerade as a legitimate user. Obtaining these tokens can be as simple as brute forcing them if they are too short or generated based on known information, such as a username. Even tokens that are generated properly can be obtained through machine-in-the-middle or the more recent adversary-in-the-middle (MiTM / AiTM) attacks or through URL parameters. A key factor in mitigating these attacks is the expiration time of a token as well as having the ability to quickly reset a token if needed. Shorter expiration times limit the amount of time that a compromised token can be used and the impact an attacker could have with one. Good practices when dealing with tokens: treat them like a secret, transport safely, generate them with sufficient length, and use signature validation when necessary.
3. Excessive Data Exposure
Excessive data exposure occurs when an API returns more information than is needed to fulfill the request. This generally happens when an API doesn’t filter out sensitive data when replying to a request and instead relies on client-side code to filter out what isn’t needed. This leaves the information unnecessarily vulnerable to both machine-in-the-middle and client-side attacks. The best control in managing data exposure is to limit the data that is returned to the user when an API call is made.
4. Lack of Resources & Rate Limiting
Rate limiting and resource exhaustion issues can occur when there are not sufficient guardrails in place around your APIs to prevent malicious actors from abusing them. Without rate limiting in place, attackers can bombard a service with requests to either occupy all the computing power that the target has or to brute force credentials more efficiently. The key to preventing these types of circumstances is determining what a normal level of requests is and limiting requests that are significantly over that threshold.
Addressing resource exhaustion attacks can be a bit more involved. The best ways to mitigate these attacks are enforcing a maximum size on all incoming parameters and payloads and limiting file submissions to specific file types to mitigate attacks such as zip bombs.
5. Broken Function-Level Authorization
Previously we discussed broken object-level authorization, which is when a user gains access to items that they shouldn’t have by manipulating the ID of an object in the request. Broken function-level authorization is when a user gains access to functionality that their user role shouldn’t have because the authorization is granted at the function level as opposed to the object level. Attackers may be able to get access to administrative functionality simply by changing an HTTP method (POST or DELETE instead of GET). Additionally, regular users may be able to access other administrative functionality just by guessing the path to that part of the API. To prevent this, the API needs to conduct authorization checks before executing function calls. This vulnerability is common in scenarios where there are a lot of role groups and complicated permissions sets.
6. Mass Assignment
Mass assignment is when a user submits a regular request to update information and includes extra data to set fields they would normally be unable to access. For example, a vulnerable API might allow a user to submit a request to change their username. But if an attacker abused this functionality by including extra fields in their request, such as an “is_admin” flag, they could upgrade their user status to admin along with allowed changes to their profile. This can be avoided by ensuring that users are only able to edit a limited number of fields and requiring administrator or system access to alter others, such as the “is_admin” or “date_created” fields.
7. Security Misconfiguration
Security misconfigurations are any issues in the settings of the API itself or the API’s host that leave it susceptible to vulnerabilities. This could include not installing regular updates and patches, overly permissive cross-origin resource sharing (CORS) policies, misconfigured HTTP headers, or detailed error messages that allow insight into the API’s functionality. Leaving default configuration settings can also be a misconfiguration. This can be avoided by integrating security testing into the API development workflow. Specifically, hardening of both the API and the underlying infrastructure, scheduled patching of API hosts, using TLS, and ensuring that unneeded information is not returned to clients when their requests result in an error.
8. Injection
Injection is a vulnerability featured on OWASP’s web application vulnerabilities list, but it can happen in APIs too. Users can inject commands, and the API processes them as if they were code that is supposed to be there. This happens when user input data is not validated, and attackers can escape out of the expected input to submit their own executable code. The best way to mitigate injection is through input sanitization. This is best left to prebuilt libraries designed for the purpose, but it boils down to validating the incoming data (ensuring data matches the required types and length), filtering out unexpected or unsupported characters, and then making the rest safe to parse (escaping special characters and specific keywords that the underlying API functionality might be looking for). Additionally, using parametrized input can help define the types of input the API will need and subsequently reduce the amount of filtering you will need to execute afterward.
9. Improper Assets Management
Let’s say that you have several versions of an API running, and over time, some could be forgotten or ignored as you make security updates and add new functionality. As time goes on, these APIs are ignored and left exposed without proper security patches. For example, if you initially published an API at a /v1/ endpoint and then released a second version at a /v2/ endpoint with some security updates without decommissioning the old version, then the old version without security updates is still accessible to attackers and could be abused. The best way to resolve an asset management issue is to create an API inventory and maintain consistent documentation throughout the development process to keep track of API versions and the endpoints they expose so that they can be updated or decommissioned as new versions are released. The inventory should also include information about the API’s lifecycle and a rollout plan for updates or mitigation tactics as needed.
10. Insufficient Logging & Monitoring
API event logging is just as important as logging network or server events. API logging will help you monitor for abnormal API usage such as authorization and authentication failures or input validation failures. You should also integrate your API logging with your SIEM and other tools for monitoring and alerting. Logging and monitoring are essential for detecting successful and attempted attacks before attackers can gain a solid foothold in your environment. before attackers can gain a solid foothold in your environment.
RH-ISAC members have access to a community of cybersecurity professionals who share identified attempted exploits and can provide advice for strengthening your applications against the top 10 API risks. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
