Rapid provides high-level security by enforcing policies in runtime and protecting against runtime attacks. Developers use Rapid to search for APIs, test APIs, and compare. With the growing number of APIs, there are larger chances for attack surfaces.
Users can control access by features, tiers, and environment with access control. We can manage who can see and use APIs by group.
APIs play a crucial role in application architecture and its security. With the increase in APIs, the overall security landscape is changing, and OWASP API Security Top 10 project was launched, which focuses specifically on the top ten vulnerabilities in API security. Further, the emergence of API-specific issues that need to be addressed led to the formulation of this project.
Here are the OWASP API security top 10 vulnerabilities:
Broken Object Level Authorization also known as Insecure Direct Object Reference (IDOR). It involves attackers replacing the ID of their own object in the API call with an ID of an object belonging to another user.
Random IDs are harder to guess, so using them instead of the sequential IDs, e.g., user_1, user_2, will protect against broken object-level authorization. Further, checking that the user has permission to access objects in every request and creating a central table/service to manage user access levels for things will also protect against IDOR.
Rapid will secure this vulnerability by automatically attaching UserID to every request (based on API Key).
Here at Rapid, enabling simple implementation of user authorization in upstream APIs is made more accessible, and it uses transformations to fit user ID into existing fields.
Weak authentication allows hackers to break into internal systems. Authentication is broken when attackers can compromise passwords, users' account information, etc., to know users' identities.
It occurs because of the single API key for all apps when there is no idea where traffic is coming from and there is no way to pinpoint anomalies. Broken authentication is prevented by checking all possible ways to authenticate to all APIs. APIs for password reset and one-time links also allow users to authenticate and prevent this from occurring.
With Rapid, API access can be granted on a developer, team, or organization level. Every app has an individual API key, and traffic is monitored per application. The built-in key rotation & user blocking (when under attack) ensures key rotation management and prevents broken authentication.
The API may expose a lot more data than what the client legally needs, relying on the client to do the filtering. Complete data includes sensitive fields, and UI layers hide those, and hackers can call API directly and get all the sensitive data.
With Rapid, you can avoid this by using a dashboard to view API response logs and identify problematic fields. You can also use transformations to prevent excessive data exposure to remove problematic areas.
The API is not protected against an excessive amount of calls or payload sizes. Hackers can scrape the API by requesting all resources. This can be prevented by limiting payload sizes and defining proper rate-limiting.
Here at Rapid, custom rate limits per API and per plan are defined, and automatic protection against known file attacks & patterns resolves this issue.
The API relies on the client to use user-level or admin-level APIs as suitable. Hackers find hidden endpoints in API and call them without permission. This can be averted by not relying on the client to enforce admin access. Only allowing operations to users belonging to the appropriate group or role can also prevent this.
Rapid creates usage tiers for the API and explicitly defines which endpoints are accessible. Endpoints that are not listed or not in the user's tier will be automatically blocked. This stops hackers from finding the hidden options in API, including all parameters, additional data, god mode, etc.
The API takes the client's data and stores it without proper filtering. Attackers can try to guess object properties or provide additional object properties in their requests or check out API endpoints to modify properties they are not supposed to on the data objects stored in the backend. Hacker reverse engineers additional fields and modifies them via requests.
With Rapid, there is automatic protection screening of all arguments for injection patterns. Further, the optional schema validation to verify request matches documented schema helps prevent this issue.
Attackers can exploit misconfiguration in API servers. Rapid uses transformation to remove or modify data returned from the server before sending it to the client. This way, attackers are unable to exploit the misconfigurations. Endpoints that are not documented are blocked by default.
Hackers insert malicious commands inside legitimate arguments to attack underlying systems. They construct API calls that include SQL, NoSQL, LDAP, OS, or other commands that the API or the backend behind it blindly executes.
Here at Rapid, there is automatic protection screening of all arguments for injection patterns. This way, hackers cannot insert malicious commands.
Attackers find non-production versions of the API that are not as well secured as the production API. These versions are used by them to launch their attacks. With Rapid, you can create different API tiers with different servers to manage environments. Each environment can be public, private, or hidden, and only the right users can access non-production environments.
Without monitoring and analytics, attacks can go unnoticed. With Rapid, all API requests are logged and analyzed. Advanced dashboarding to visualize and query API logs further prevent these attacks.