Today, the world runs on technology powered by robust data ecosystems connected via APIs. Our mobile and desktop apps, IoT-enabled smart devices, financial institutions, and more all run on the tech that's powered by APIs under the hood.
Humankind has witnessed that the more popular and widely accepted tech gets, the bigger of a target it becomes for security attacks. New kinds of attacks and their respective remedies appear constantly. In order to keep their applications and APIs secure, organizations need to keep up with API security best practices.
What Are the Common API Security Risks?
The Open Web Application Security Project, known as the OWASP Foundation, is a nonprofit foundation that works to improve the security of software. OWASP maintains a list of the top 10 API security risks to which security researchers across the globe contribute. These are said to be industry benchmarks when it comes to API security. Just by mitigating these security risks, organizations can reduce attack vectors significantly. Let's walk through some of these common API security risks to ensure a more secure application architecture.
1. Broken Object Level Authorization
Broken Object Level Authorization, or BOLA, is a lack of resource ownership validation before serving requests. This means that the server doesn't validate the relationship of ownership between the client and the requested object. That may lead to anyone being able to access anything.
For instance, in an e-commerce application, you might have a "View My Orders" section that runs off a GET API that lists all the order IDs associated with your user ID. Then there's another API that serves detailed information based on an order ID without further checking whether the requested resource belongs to the client or not.
This can be easily exploited by trying multiple combinations of the order IDs and "getting lucky," by finding that the underlying table in the database is set up in a way that auto increments the order IDs while creating.
Now, suppose the attacker has access to any order ID. In that case, they can go up or down that range and potentially get personally identifiable information off those incremental order IDs, such as the contact or delivery address for an order.
The solution is to always check if the client is authorized to access the requested resource(s) or not. There's no better or simpler way to put it.
2. Broken User Authentication
Generally, all our application's pages sit behind either a login or a public sign up page. This presents these access methods as a target that attackers can exploit. Some common authentication issues include weak password policy, sending passwords in clear text to the server, trusting that all users are humans (no CAPTCHA), and weak or no encryption.
Companies can mitigate login or sign up vulnerability risks by implementing brute-force-resistant mechanisms such as rate limiting, CAPTCHA, stronger password policies, account inactivity timers, etc., to ensure the users are authenticated at all times.
OWASP provides a single reference point of authentication guidelines documented in their Authentication Cheat Sheet.
3. Excessive Data Exposure
Excessive data exposure is, in effect, where data is picked off the database and sent to the client without any sensitivity filtering or fine access control within a RESTful API.
This vulnerability can be easily identified and caught by requesting to fetch data off your server and examining the API responses. These responses will always consist of data or metadata that the client isn't supposed to be looking at.
The solution here is to get a good grasp on the application's business logic. That will allow you to only send data required by the client and nothing else. This, at scale, also decreases the size of your API responses, leading to lower bandwidth costs.
4. Lack of Resources & Rate Limiting
Lack of rate limiting means that your server will keep accepting requests until it just can't anymore. Not imposing a limit on how many requests can be sent to a server makes it vulnerable to Denial-of-Service (DoS) attacks. In DoS attacks, the server can be flooded with too many requests. Eventually, this could lead to the server breaking down and causing an outage, thus a loss of actual and potential revenue.
This vulnerability can be easily identified by hitting any server with a barrage of requests (aka load testing) and checking if it breaks down.
There are several ways to enforce rate limiting on a server. Here's a detailed blog for readers who want to dive deeper into a Node.js implementation.
5. Broken Function Level Authorization
Broken function level authorization is where administrative actions are available via REST APIs but lack authorization on the function level. Essentially, the system does not recognize the difference between admin users and regular users. Therefore, it'll grant access to everyone and allow administrative actions to be run.
Attackers could quickly identify this by exploiting the API URL's general REST API principles and nomenclature. Merely changing the GET user's API method to PATCH or DELETE might give regular users destructive capability without authorization.
A straightforward solution is to block all actions as a default config. Then you open up actions to certain users or user types only when required. With administrative actions, it's much better when admin users are not able to use them compared to regular users also being able to use them.
6. SQL Injection
Many applications build SQL queries based on user input—for example, text input for string comparison. Let's look at an example of an order cancellation query. In this case, an order ID is expected to be sent by the client as a query parameter in the Delete API URL itself. Here, the following query template is expecting the order ID:
const query = `DELETE FROM Orders WHERE OrderId = ${req.query.orderId};`;This could let attackers have direct access to your database where they can, instead of the order ID, call:
DELETE /api/orders?orderId=123%20OR%201%3D1This will ultimately build the following SQL query:
DELETE FROM Orders WHERE OrderId = 123 OR 1=1;The SQL query generated above is valid and thus will delete all rows from the Orders table since OR 1=1 is always True.
The solution could be strict parameter checking for the URL query. However, the rule of thumb is to never trust user input. Always sanitize user input with well-recognized input sanitization libraries. That will ensure that, if you're expecting the orderId in the route's query params to be an integer, it's nothing except that. Many libraries have been made to solve this problem. You could go with any of the popular ones actively maintained by the open-source community.
The rule of thumb is to never trust user input.
API Security Risks: Conclusion
As ever-evolving as security risks are, best practices and industry standards can ensure the security of APIs and overall applications. Multiple of these security risks are pretty simple to exploit, yet also simple to understand and mitigate. Developing applications with a security-first mindset is highly advised, as it saves teams redundant effort.
Safeguarding APIs against some of these common security risks will drastically reduce attack vectors and surface area provided to attackers. Most of the discussed security risks are easy to exploit but can be protected against to keep your organization safe.
This post was written by Keshav Malik. Keshav is a full-time developer who loves to build and break stuff. He is constantly on the lookout for new and interesting technologies and enjoys working with a diverse set of technologies in his spare time. He loves music and plays badminton whenever the opportunity presents itself.
