APIs matter. Not only are they fueling digital transformation, these application building blocks are increasingly playing a key role in our economy. According to Postman’s 2023 State of the API report, “almost two-thirds of respondents said their APIs generate revenue. Of those respondents, 43% said APIs generate over a quarter of company revenue.”
Yet this growing corporate attack surface is not without risk. In the first article in our three-part series on OWASP Top 10 API Security Risks, we examined the top three risks on the 2023 list: Broken Object Level Authorization, Broken Authentication and Broken Object Property Level Authorization. In this second article in the series, we’ll examine additional risks: Unrestricted Resource Consumption, Unrestricted Access to Sensitive Business Flows and Security Misconfiguration.
Security Misconfiguration: APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don’t follow security best practices when it comes to configuration, opening the door for different types of attacks.
Security misconfiguration is one of the most complex and most difficult API risks to identify and manage. Security misconfiguration may be due to a number of factors including: missing security hardening across any part of the API stack; improperly configured permissions on cloud services; missing or out-of-date security patches; out-of-date systems; unnecessary features are enabled (e.g. HTTP verbs, logging features); discrepancies in the way incoming requests are processed by servers in the HTTP server chain; and missing Transport Layer Security (TLS).
Improper involuntary management can also contribute to security misconfiguration. Developers need to actively manage what code should and should not be active; otherwise, you can quickly lose control which version is being used for what customer and where the API is being deployed, whether it is in production, QA, etc.
Unrestricted Access to Sensitive Business Flows: APIs vulnerable to this risk expose a business flow – such as buying a ticket, or posting a comment – without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn’t necessarily come from implementation bugs.
Unrestricted access to sensitive business flows is very risky and can have a significant impact on revenue and corporate reputation. Today I’m seeing this risk in every industry, whether it is in entertainment, airline, hospitality, or finance. For example, let’s say an organization has set a concert ticket limit. With unrestricted access, an attacker would be able to purchase an unlimited number of tickets and resell them on an external market at higher prices.
When organizations do restrict access, they need to make sure that the IP addresses are not coming from Tor or something already blacklisted. Is there a human factor involved, whether the Captcha or typing pattern is there, or can you apply a fingerprint or a device registration? For example, registering my device with Best Buy can help Best Buy ensure that only authorized customers can access its’ online store.
Unrestricted Resource Consumption: Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase of operational costs.
Unrestricted resource consumption, also known as resource exhaustion, is a type of denial-of-service (DDoS) attack that aims to exhaust the resources of a target system or application. The MITRE corporation lists three possible scenarios that could lead to resource exhaustion: lack of throttling for the number of allocated resources; losing all references to a resource before reaching the shutdown stage; and not closing/returning a resource after processing.
To reduce the risk of unrestricted resource consumption, organizations can take a number of preventive steps including: Use a solution that makes it easy to limit memory, CPU, number of restarts, file descriptors, and processes such as Containers / Serverless code (e.g. Lambdas); define and enforce a maximum size of data on all incoming parameters and payloads, such as maximum length for strings, maximum number of elements in arrays, and maximum upload file size (regardless of whether it is stored locally or in cloud storage); implement a limit on how often a client can interact with the API within a defined timeframe (rate limiting); fine-tune rate limiting based on the business needs; limit/throttle how many times or how often a single API client/user can execute a single operation (e.g. validate an OTP, or request password recovery without visiting the one-time URL).
In our final piece in this three-part series on the OWASP Top 10 API Security Risks list, we will look at the future of API protection, the potential impact of AI, if any, and what enterprises can do to help reduce API risks.