OWASP Top 10 API security risks: Unsafe consumption of APIs

Number 10 on the Open Worldwide Application Security Project® (OWASP) Top 10 API Security Risks for 2023 is unsafe consumption of APIs.

When working with well-known companies and third-party APIs, there’s usually a higher level of trust than from individual users. However, if someone infiltrates the third party, this trust can be violated, leaving your networks exposed and allowing for unsafe consumption of APIs.

Attack vectors

This type of attack has created significant problems for companies. By identifying and compromising other APIs or services that your APIs interact with, attackers may gain access to your systems. These attacks can be somewhat difficult to detect immediately as traffic through the third party may appear to be authorized and authenticated, so even if you have robust security controls and alerts in place, you may not get flagged unless attackers then try to access unauthorized areas.

Security weaknesses

Unsafe consumption of APIs is a fairly common attack vector, especially when developers do not verify endpoint interaction with external or third-party APIs. These APIs may be subject to less stringent security requirements, such as:

• Transport security
• Authentication
• Authorization
• Input validation
• Sanitation

Business impacts

The impact of this type of security risk will vary depending on the business and industry, but it can be severe. A compromised system can be injected with malicious software and ransomware. Exfiltration of sensitive or proprietary data can cause significant harm. Unsafe consumption of APIs can be the source of denial-of-service attacks.

How unsafe consumption of APIs works

Unsafe consumption of APIs can be as simple as attackers exploiting vulnerabilities in other applications and networks and then using APIs to backdoor into your systems. Threat actors might use the third party to store malicious payloads masked as legitimate information. When an API pulls this information into its system, the payload gets executed and pulls data to a server controlled by the hacker.

Attackers may also find a way to compromise third-party APIs and detect patterns in responses to requests. Using these patterns, they may be able to redirect data requests to the attacker rather than back to the third party.

Real-world examples

One recent example of an unsafe consumption of APIs was the infamous Log4Shell vulnerability, which the National Vulnerability Database (NVD) government repository rated a 10 out of 10 on its threat assessment. Apache Log4j is widely used in code and featured fairly permissive access from user-controlled input over APIs. When a service used Log4j within its codebase to log incoming API requests or responses, this attack could execute arbitrary code on the server hosting the application.

Researchers found that payment provider Venmo’s API could be abused to scrape data about transactions and other sensitive information. The API was designed to display a feed of transactions on the home page of the app, but it was left open to authenticated requests, according to researchers who were able to scrape data of more than 200 million private transactions.

A location tracking tool available online was meant for demo purposes, but it was exploited by users that could easily bypass authentication requirements. As such, users were able to put in mobile phone numbers and track users' whereabouts until the demo was pulled offline.

Detecting unsafe consumption of APIs

Detecting unsafe consumption of APIs requires similar approaches as other API exploits, including active monitoring of usage patterns looking for unusual spikes in API requests by users, uneven traffic distribution, or API requests for non-public consumption.

API scans can help uncover unprotected APIs or endpoints for mitigation. Organizations may want to deploy penetration testing to detect vulnerabilities and user behavior profiling to detect anomalies from baseline analysis.

Security teams need to regularly review access and error logs from API gateways for unusual activity, such as requests from unauthenticated IPs or increased error rates. Alarms should be put in place to detect unsafe API access for warning signs, including requests that exceed limits, indicate bot activity, or produce repeated token failures.

Payloads should also be inspected for common attack patterns, such as malicious files, code injection, or parameter tampering.

Preventing unsafe consumption of APIs vulnerabilities

Developers need to put in place strict security protocols for authorization and authentication while paying extra attention to third-party APIs. OWASP recommends:

• Interacting with other APIs on encrypted channels
• Validating and sanitizing data from other APIs before processing it or passing it to downstream components
• Avoiding API configurations that blindly follow redirects
• Enforcing global rate-limiting policies and limiting resources available to process third-party requests
• Implementing timeouts for interactions

When evaluating service providers, it is important to assess their API security posture and ensure that all interactions take place over a secure communication channel, such as TLS. Developers should also maintain strict allowlists for where integrated APIs may redirect traffic.

Organizations can also provide additional layers of protection by encrypting sensitive data at risk and requiring validation certification to prevent man-in-the-middle attacks. The bottom line for any security approach is to deploy a multilayered approach to monitor authentication and verification before data is accessed.