Posted on Oct 20 • Originally published at api7.ai 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: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.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.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.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: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: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: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: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: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.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.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.🙋 Join the Apache APISIX Community🐦 Follow us on Twitter📝 Find us on Slack💁 How to contribute pageVisit my blog: www.iambobur.comTemplates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse sudha - Oct 19 michelebitetto - Oct 19 Madza - Oct 17 Zamzam Hassan - Oct 19 Once suspended, apisix will not be able to comment or publish posts until their suspension is removed. Once unsuspended, apisix will be able to comment and publish posts again. Once unpublished, all posts by apisix will become hidden and only accessible to themselves. If apisix is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Bobur Umurzokov. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag apisix: apisix consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging apisix will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.