How APISIX protects against the OWASP top 10 API security threats

With the increasing usage and reliance on APIs in today's interconnected digital landscape, security threats targeting them have also grown over the years. In 2023, the Open Web Application Security Project (OWASP) identified the new Top 10 threats to API security. In this blog post, we'll explore each threat and learn how APISIX can protect against them with examples.

The OWASP is a globally recognized community that publishes regularly cybersecurity-related research.

Here is the list of OWASP-mentioned security risks:

1. Broken Object Level Authorization
2. Broken Authentication
3. Broken Object Property Level Authorization
4. Unrestricted Resource Consumption
5. Broken Function Level Authorization
6. Unrestricted Access to Sensitive Business Flows
7. Server-Side Request Forgery
8. Security Misconfiguration
9. Improper Inventory Management
10. Unsafe Consumption of APIs

1. Broken Object Level Authorization

Threat: APIs often expose endpoints that handle object identifiers, which can lead to Object Level Access Control issues. Attackers can exploit these vulnerabilities to gain unauthorized access to data.

Example: A healthcare institution offers an online patient portal. Due to a flaw in the portal's design, once a patient is authenticated, they can modify the URL or request parameters to access medical records associated with a different patient ID. For instance, a patient Steve logs into the patient portal to view his medical records. His records are accessible via the URL https://healthportal.com/patient/123. Curious, Steve changes the URL to https://healthportal.com/patient/124 and discovers that he can now view the medical records of another patient. This exposes a significant privacy breach and violates regulations like the Health Insurance Portability and Accountability Act (HIPAA).

Recommendation: Implement a proper authorization mechanism that relies on the user policies and hierarchy. APISIX gateway supports OAuth2 or JWT-based authorization flows with the help of plugins. You can use the OAuth2 policy to verify the token on each request.

Use fine-grained access control through the APISIX Role-Based Access Control (RBAC) system by integrating with Open Policy Agent (OPA). By setting up specific roles and permissions in APISIX and associating these roles with specific users or tokens, you can ensure that requests to sensitive endpoints are properly authorized.

2. Broken Authentication

Threat: Incorrectly implemented authentication mechanisms can allow attackers to compromise authentication tokens or simply an attacker brute-force login endpoints because there's no rate limiting.

Example: The banking system implemented a custom authentication mechanism. However, due to a lack of proper security review and testing, there was a vulnerability in the authentication flow. Specifically, after a user entered their username and password, the system generated a predictable session token, such as a combination of the username and a timestamp. An attacker, aware of this defect, could easily predict the session token of another user.

Recommendation: First, understand all possible authentication flows to the API, and don't reinvent the wheel in authentication! APISIX supports standard OpenID Connect (OIDC) authorization flow. Instead of predictable session tokens, APISIX can integrate with external identity providers like Keycloak or session management systems using plugins to ensure that session tokens are random, encrypted, and have a limited lifespan.

To prevent brute force attacks on user accounts, APISIX's rate-limiting plugin can be used. This ensures that if there are multiple failed login attempts in a short period, the IP or user is temporarily blocked. To ensure data privacy and integrity, APISIX supports SSL/TLS encryption. This ensures that user credentials and other sensitive data are encrypted during transmission.

3. Broken Object Property Level Authorization

Threat: This threat arises from the lack of or improper authorization validation at the object property level, leading to unauthorized information exposure or manipulation.

Example: An online shopping platform’s API allows registered users to update their profile details such as name, email, shipping address, and payment details. Additionally, each user profile has a property called userType, which can be either regular or admin. Due to an issue in the API's design, users can also modify the userType property in their profile update requests. Assume that Alice, a regular user, discovers this flaw when she inspects the API requests using her browser's developer tools. She notices that when updating her profile, a JSON payload is sent to the server. Alice modifies the userType value to admin and sends the request. To her surprise, her profile is updated, and she now has administrative privileges on the platform, allowing her to access sensitive data, modify product listings, and even view other users' order histories.

Recommendation: Ensure that exposed object properties are accessible to the user and keep returned data structures minimal, based on business requirements. To achieve this, you can use APISIX a request-validation plugin that can validate incoming requests against a predefined schema. Or use APISIX's RBAC system to set up roles for regular users and admins. To remove unnecessary data that is exposed to the client, APISIX provides a response-rewrite plugin that can modify the API response on the fly.

4. Unrestricted Resource Consumption

Threat: Attackers can exploit APIs to consume excessive resources, leading to Denial of Service attacks or increased operational costs.

Example: A cloud-based file storage service allows users to upload and store files, share them with others, and access them from anywhere. The service does not have any restrictions on the number of files a user can upload simultaneously or the size of each file. As a result, a malicious user or a bot can upload an enormous number of extremely large files in rapid succession, consuming a significant amount of server resources. This can lead to slower response times for other users, potential server crashes, and increased infrastructure costs for the service provider.

Recommendation:

• Define and enforce maximum data sizes for all incoming parameters and payloads. Use the client-control plugin to set the max size of the request body so that users can't upload excessively large files. Or use the request-validation plugin to validate query strings, especially those controlling the number of records returned. To block a bot, script, or user agent from sending unwanted data, you can leverage the ua-restriction plugin.
• Implement rate limiting based on business needs. APISIX provides limit-req, limit-conn, and limit-count plugins that can restrict the rate at which an individual user or IP address can make requests. This ensures that users can't flood the system with a large number of rapid requests.

5. Broken Function Level Authorization

Threat: Access control policies are sometimes too complex, with various levels, groups, and roles, and a blurred distinction between administrative and standard functions, often results in permission vulnerabilities. Attackers can take advantage of these weaknesses to access resources of other users or administrative features.

Example: An online learning platform offers various courses to students. With problems with the platform's design, students can access instructor-only functionalities by manipulating URLs or API endpoints. For instance, a student might discover that by changing the URL from /student/dashboard to /instructor/dashboard, they can access the instructor's dashboard, allowing them to modify course content, grade assignments, or even add/remove courses.

Recommendation:

• Deny all access by default and require explicit grants for specific roles. With APISIX, you can create a consumer or a group of consumers to give different access control for users. Then, the JWT authentication plugin can be configured to include role information in the JWT token. When a user logs in, the JWT token they receive will contain their role (student or instructor). APISIX can then verify the user's role from the JWT token before granting access to specific functions.
• Ensure administrative controllers inherit from a controller that implements authorization checks based on user roles. If you use API7 enterprise, it allows admins to limit API access to particular users/groups and you to set up access on a per-request and per-user basis.

6. Unrestricted Access to Sensitive Business Flows

Threat: Sensitive business flows are exposed without risk evaluation of how the functionality could harm the business if used in an automated and excessive manner.

Example: Using a combination of proxies and automated scripts (bots), the attacker simulates multiple real users making purchases. The script rapidly adds the product to the cart and completes the checkout process, finishing the stock before real customers have a chance to make a purchase. The attacker then resells these products at a higher price on other platforms. The seller platform loses potential revenue as they can't sell the products to actual customers at the intended price.

Recommendation:

• Implement device fingerprinting to deny service to unexpected client devices. APISIX can be integrated with identity and access management platforms like Auth0, Authgear, and so on to enable different authentication mechanisms including biometric login features on devices.
• Use human detection mechanisms like captchas or advanced biometric solutions. The same as above.
• Analyze user flow to detect non-human patterns. You can use API7 enterprise to enforce extra factors of authentication when a request is associated with non-human patterns, such as high speeds between different login locations or detecting bots.
• Block IP addresses of known malicious sources. APISIX has an ip-restriction plugin to block access from single or multiple IP addresses.

7. Server Side Request Forgery (SSRF)

Threat: SSRF attacks allow an attacker to make requests to internal resources of the server, potentially gaining access to internal networks, file systems, or even executing commands. This happens when an API endpoint accepts a URL or a part of it as input and fetches it without proper validation.

Example: An API endpoint accepts a URL to fetch an image from the internet. A malicious user submits a URL like http://169.254.169.254/latest/meta-data/ (a typical metadata endpoint in cloud environments). The service fetches the URL, thinking it's an image, but instead retrieves sensitive data like IAM roles, secret keys, or other internal configuration details. The attacker then uses this information for further attacks, like privilege escalation or data breaches.

Recommendation:

• Input Validation - Always validate and sanitize inputs. Avoid accepting full URLs from untrusted sources. With APISIX, you can set up a uri-blocker plugin to apply blocking rules to internal resources.
• Whitelisting - Only allow connections to known and trusted domains or IPs. The same you can use the APISIX’s ip-restriction plugin or enable referer-restriction for a whitelist of acceptable domains or URL patterns. Any URL not matching the whitelist is rejected.
• Network Segmentation - Ensure that your servers are segmented, and sensitive internal resources are not directly accessible.

8. Security Misconfiguration

Threat: This occurs when an API is not securely configured, potentially exposing sensitive information or granting unnecessary permissions. Examples include logging error messages revealing server details, unnecessary HTTP methods enabled, or default credentials left unchanged.

Example: A simple example could be an API unintentionally exposing a .git directory, revealing source code and commit history. Another example, a malicious user, while using your platform, encounters an error message. Instead of a generic error message, he sees a detailed stack trace revealing database structure, software versions, and file paths. Using this information, he identifies potential vulnerabilities in the platform. Additionally, upon researching common misconfigurations for such platforms, he tries logging in with the test account and succeeds, granting him administrative access.

Recommendation:

• Regular Audits - Regularly review and update configurations. Use automated tools to scan for common misconfiguration. With APISIX's logging plugins, all access and system activities are logged. Any unusual activity, like repeated login failures or access to restricted endpoints, can be flagged for review.
• Principle of Least Privilege - Only grant necessary permissions and avoid using overly permissive settings.
• Default Security Headers - APISIX enforces secure defaults with essential security headers, like Content Security Policy (CSP) and HTTP Strict Transport Security (HSTS), which are set. This reduces the risk of certain web-based attacks.
• Error Masking - Ensure that error messages are generic and do not leak sensitive information. APISIX can be configured to mask detailed error messages using the response-rewrite plugin or custom data mask plugin.

9. Improper Inventory Management

Threat: As organizations grow, they often lose track of all their APIs, especially if there's no centralized management. This can lead to forgotten, outdated, or unprotected APIs that can be exploited.

Example: It is common for multiple versions of APIs to be left unmonitored. Attackers might target outdated API versions or unpatched access points. They can also gain unauthorized access through vulnerabilities in third-party connections.

Recommendation: Use APISIX's Admin API to regularly review and deactivate routes that are no longer needed and to keep track of all API versions without disrupting client apps. API7 Portal provides a centralized management dashboard where all APIs can be monitored and managed. An old version of an API might still be running and it's no longer used. Through the dashboard, this API can be identified and shut down without any code change in the backend service itself.

10. Unsafe Consumption of APIs

Threat: When integrating third-party APIs or even consuming internal APIs, if not done securely, the action can expose the application to vulnerabilities present in the upstream APIs.

Example: Let’s think of a mobile application that allows users to monitor their health metrics, such as heart rate, sleep patterns, and physical activity. The application does not have strict validation and security checks when consuming these third-party APIs. An attacker identifies that one of the integrated nutrition tracker APIs is vulnerable and can return malicious data. When the application fetches meal plan suggestions from this API, it unknowingly retrieves and processes malicious payloads, leading to potential data breaches or application malfunctions.

Recommendation: Before integrating a third-party API, check if it's from a reputable source and has undergone security assessments.

• Error Handling - Handle unexpected responses or behaviors from consumed APIs without exposing vulnerabilities.
• Data Validation - Always validate and sanitize data received from third-party APIs. APISIX can be integrated with Web Application Firewalls (WAF) to inspect and filter incoming data from third-party APIs. This can detect and block known malicious patterns or payloads. It is also possible for you to activate TLS/mTLS for upstream services to guarantee the security of traffic while it is traveling through the internal network.

Summary

Applying the suggested security guidelines from OWASP API 2023 provides a foundational starting point for safeguarding APIs. Using APISIX Gateway features simplifies this process and significantly reduces the cost of implementing OWASP-recommended prevention mechanisms.

Related resources

• Secure APIs in an API Gateway
• API Gateway Authentication
• Prevent Sensitive Data From Leaking in API Gateway

Community

🙋 Join the Apache APISIX Community

🐦 Follow us on Twitter

📝 Find us on Slack

💁 How to contribute page

About the author

Visit my blog: www.iambobur.com