As the Open Web Application Security Project (OWASP) – a not-for-profit foundation that focuses its efforts on improving software security – notes, the application programming interface (or API) has become the foundation for today’s ‘app-driven world’. “From banks, retail, and transportation to IoT, autonomous vehicles, and smart cities, APIs are a critical part of modern mobile, SaaS, and web applications and can be found in customer-facing, partner-facing, and internal applications,” writes the team. Widely deployed, APIs are part of the attack surface targeted by malicious actors, which is why it’s important for developers to understand the top API security risks and know how to fix them.
Whether you are building APIs using the SOAP protocol or implementing RESTful architecture, OWASP provides a useful 10-point checklist of the common pitfalls that developers face. And, importantly, the guide offers suggestions on how firms can address top API security risks. Top of the API vulnerability list is Broken Object Level Authorization.
Broken Object Level Authorization
Object level authorization is the mechanism deployed behind the scenes, which makes sure that API users only have access to objects, or data, that they are authorized to see. If the object ID received by the API endpoint is predictable and unchecked, then bad actors can simply change its value in the URL request to discover information that should otherwise be protected. To secure the API endpoint and shut down one of the top API security risks, OWASP recommends that global unique identifiers (GUIDs) should be random. And values need to be validated so that users can only perform actions on objects that they have genuine access to.
Broken User Authentication
Closely related to Broken Object Level Authorization is Broken User Authentication, where vulnerabilities in the API’s user authentication mechanism give attackers access to user accounts on the system. Developers can quickly identify whether their setup is susceptible to one of the top API security risks by asking the following questions:
- Does the API allow bad actors to try multiple pairs of valid user ids and passwords – in other words, perform credential stuffing? A countermeasure to this would be to enable multi-factor authentication (MFA).
- Can attackers conduct a brute force attack – for example, by targeting a user account with hundreds of password combinations? Defenses here include limiting the number of password attempts or enabling captchas.
- Are strong password policies enforced, or can users specify easily-guessable words, phrases, or numerical sequences?
- Does the URL readily display sensitive authentication information such as passwords or authorization tokens? And are passwords exposed in plain text? Also, are authorization tokens validated at the backend? Passwords should be hashed and communications strongly encrypted.
Excessive data exposure
The best practice here, to avoid another one of the top API security risks, is to make sure that all data is filtered on the server side. Clients should receive just the data that they are entitled to see and nothing more – even if it is hidden to the user. Any additional data included within API responses will inevitably be discovered at some point. If the developer is lucky, it’ll be found by a security researcher who’ll report it through a vulnerability disclosure mechanism (if the API operator has one). But the danger is that a malicious user will simply hoover up all of the excess sensitive information, which is not a good look, potentially adding to an already long list of data breaches worldwide.
Other common API security pitfalls
It’s important that API endpoints can put limits on the size and number of requests that can be sent by clients or users. Failure to do so exposes the API endpoint to denial of service (DOS) or distributed DOS (DDOS) attacks. The absence of any rate limiting or throttling mechanism also exposes the API endpoint’s authentication mechanism to brute force attacks, as touched on above.
Regular users shouldn’t be able to access administrative endpoints. Bad actors will attempt to guess API endpoint URL parameters based on any exposed hierarchy, such as roles or groups used by the application. To harden systems, it’s important that API endpoints are thoroughly reviewed to identify any potential function level authorization flaws.
Properties that can be assigned by clients should be allow listed – for example, to prevent bad actors from setting their credit to ‘999999’. Also the entire API stack should be screened for possible security misconfiguration. Only HTTP verbs that are required by the API endpoint should be allowed. Any unrelated HTTP verbs should be disabled to reduce the attack surface and mitigate top API security risks.
Other common API security vulnerabilities to be watchful of include injection flaws. Malicious users could attempt to fool the interpreter into sending restricted data or executing unauthorized actions by including untrusted data within a command or query. Attention also needs to be paid to asset management, as well as logging and monitoring (to make sure that any potential API tampering doesn’t go unnoticed).
