APIs are the bridges of digital ecosystems connecting our systems, data, and services to the outside world. But with great power comes great responsibility. Vulnerable APIs can result in financial losses, reputation damage, and operational paralysis. To secure our APIs, we must first understand the risks and what these vulnerabilities are, have actionable steps to prevent them, and have the right tools to detect and mitigate them. In this article, we'll look at some of the common API vulnerabilities, how to prevent them, and some tools to help us.

Photo by Alexander Rotker on Unsplash

According to Astra, the number of unique API attacks increased by 60% year over year from 2022 to 2023. A Data Theorem report conducted by Enterprise Strategy Group surveyed nearly 400 organizations and found that 92% experienced at least one security incident related to insecure APIs in the past 12 months. Industry specific numbers are even more staggering, especially the financial services and insurance verticals. Check these links to view some of the recent API security breaches: 1, 2.

High level security challenges

1. Volume & Speed. The size, complexity and fast-changing nature of the API ecosystem creates several major security challenges
2. Authentication. According to the FireTail API Data Breach Tracker, most API breaches involve at least one authentication or authorization vulnerability.
3. Critical Data Identification. Identifying the critical data and how it moves through the API ecosystem. Enterprises need to figure out where their most sensitive data is and prioritize API security based on which ones have access to that data.
4. Lack of knowledge & visibility. With multiple applications and siloed teams, IT departments, lack of common standards & governance, there's a lot of APIs being consumed and produced. Not all teams are aware of security and security teams can't secure something they can't see.
5. Lack of dedicated security function. Not all orgs may have a dedicated security function.

OWASP API Top Ten API Risks

The Open Worldwide Application Security Project (OWASP) is a community led nonprofit foundation that works to improve the security of software, primarily through comprehensive documentation and standards around security issues. The OWASP API Security Project publishes and maintains a Top 10 API Security Risks document which underscores the most common risks. Here's a list of top 10 Security Risks as per the 2023 report with some potential prevention mechanisms.

Photo by Alexander Rotker on Unsplash

1. Broken authorization: The lack of authorization checks can allow attackers to access resources they're not allowed to. E.g. user 1 can access user 2's data by simply changing ID in the URL (/user/2). Any action that is performed on an object/data, should have authorization checks in place. The logged in user's permissions should be checked to see if the intended action is allowed. User policies with hierarchies, using random IDs, checking authorization for each client request, not relying on IDs sent by clients are some of the prevention mechanisms.
2. Broken authentication: This refers to the authentication mechanism details. Credential stuffing, brute-force attacks, weak passwords, authorization tokens and passwords embedded in the URL, etc. are some examples that expose this vulnerability.
3. Broken object property level authorization: Even when users are allowed access to particular objects, they might not necessarily need access to all the properties of those objects. E.g. An admin has access to view other users but not their social security number. For prevention, have a well defined schema for all API responses with well defined roles for properties, filter data on server, identify sensitive data like PII, etc.
4. Unrestricted resource consumption: Each API call uses resources like bandwidth, CPU, memory, and storage. Unrestricted access can overload and consume all resources and make systems unavailable — a DDoS attack. E.g. an attacker could send thousands of password reset requests. To prevent these attacks, apply rate limiting to all endpoints, especially ones related to authentication. Limit request and reponse payload sizes. Limit the amount of data that can be requested in a single request. Add alerts and limits on compute resources. Most cloud providers have a DDoS protection layer that should be leveraged if possible.
5. Broken function level authorization: When API calls are made, these API calls in turn make other system calls. This vulnerability occurs when an API call to specific functions don’t check if the user has the right privileges. E.g. an end user might be able to create a new user account with admin privileges. Each business function should have role-based authentication. By default, deny all requests.
6. Unrestricted access to sensitive business flows: APIs vulnerable to this risk expose a business flow without metering in place. E.g. buying a ticket, or reading articles behind a paywall, posting comments. Such flows should be identified, documented and extra layer of prevention should be added for these cases. Create a framework or core level checks so that making these APIs secure is a higher level function.
7. Server-side request forgery: This vulnerability occurs when an API is fetching a remote resource without validating the user-supplied URL. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. Always sanitize and validate user supplied URL (or any data for that matter).
8. Security misconfiguration: APIs may be running on systems that are not patched with latest security updates, or have misconfigured permissions, or have more features enabled allowing user access in areas not needed, etc. If API responses display error messages or send headers that reveal more than they need to, it can open more doors. For prevention, the API code stack, containers, web servers, etc. should be automatically hardened and patched. Admin access should be disabled and unnecessary features should be disabled. API responses should be sanitized.
9. Improper inventory management: When APIs are retired and deprecated and not maintained anymore, they can become vulnerable because of a hosts of reason. Test/staging/non-production APIs, backward compatibility code, etc. can open this vulnerability. Create a living inventory that documents each API, it's purpose, an active version, access check and blind spots. Implement strict authentication, redirects, CORS. Backport security fixes, retire old versions. Limit access to non-production APIs. Consider using OpenAPI specification for documenting APIs. OpenAPI enables developers to create comprehensive, well-structured API documentation. Clarity in documentation is foundational for robust API security, as it empowers both developers and security teams to understand how the API works, API access, identify potential vulnerabilities and enforce best security practices..
10. Unsafe consumption of APIs: This happens when an API consumes another upstream API which itself is vulnerable. For prevention, just like user data, upstream API data should be sanitized and validated before consumption.

Tools

There are several services and tools designed for the discovery and prevention of API vulnerabilities.

• Discovery and Assessment Tools: OWASP ZAP, Postman, Swagger, Noname Security, Acunetix, etc.
• Security Scanning and Analysis: Veracode, Checkmarx, Snyk, etc.
• API Protection and Management: Apigee, AWS API Gateway, Azure API Management, Kong, Tyk, Apache APISIX, etc.
• Threat Protection and Monitoring: Cloudflare, Imperva, Signal Sciences, Wallarm, CloudVector, etc.
• Encryption and Data Security: Fortanix, Protegrity, Thales, Ionic Security, etc.
• Compliance and Policy Enforcement: Cyral, Axway, Cloudentity, 42Crunch, etc.
• Error Handling and Logging: Sentry, Rollbar, Bugsnag, Airbrake, etc.

Source: Wikipedia

Key takeaways

1. Frequent Vulnerability Assessments: Conduct regular security assessments to identify vulnerabilities in your API design, implementation, and configuration. Think of it as a security stress test, exposing weak points before attackers do.
2. Developer Enablement. Provide developers with the tools and training they need to build secure APIs. This includes security best practices, code samples, and security testing tools. Invest in building frameworks and libraries that can be reused across teams. Leverage automation and DevOps to make security a part of the development process and remove friction.
3. Vigilant Monitoring: Continuously monitor APIs for suspicious activity. Use dedicated security tools and analytics platforms to detect anomalies, unauthorized access attempts, and potential breaches.
4. Patch & Update: Regularly update your APIs, libraries, and underlying infrastructure with the latest security patches.
5. API Gateways: Consider deploying API gateways. These sit at the front door, managing traffic, enforcing security policies, and shielding your backend systems from direct attacks.
6. Shift Left. Security should be a part of the development process from the beginning. It should be a part of the design, development, testing, deployment and maintenance phases. It should be a part of the culture and not an afterthought.

APIs are gateways to opportunity, but also to risk. By prioritizing API security, we can ensure these bridges remain pathways to innovation and collaboration, not vulnerabilities.

Let me know your thoughts.