Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
What are we talking about here, and why should we even care? Below is a breakdown of the top 10 API risks for this year, explained.
- Broken Object Level Authorization
- Explanation: An API may not be properly verifying whether the requestor should have access to an object like a file, data in a database, or something similar.
- Example: our url is example.com/api/user/123 but the attacker may be able to change the ‘123’ to some other user id and be allowed to access whatever that user id would be able to access.
- Engineer’s Perspective: The API endpoint needs to be checking to make sure that the user token being used for a request is allowed to access the object being requested.
- Broken Authentication
- Explanation: User accounts with simple passwords and no two factor auth can be cracked via brute force or interception an auth token.
- Engineer’s Perspective: Password complexity is key, as well as implementing multi-factor auth for user accounts. In addition, requiring re-authentication for sensitive operations can help. In addition, the security for password recovery endpoints and the password recovery process needs to be just as important as login security. Obviously, use encryption on all endpoints as well.
- Broken Object Property Level Authorization
- Explanation: Similar to the broken object level vulnerability above, except this pertains to the more granular level of the properties of an object. So this is more than access, this might be modification of an object the requestor shouldn’t have access to at all.
- Engineer’s Perspective: API endpoints not only need to check to be sure if a user can access an object, but know what properties of the object are allowed to be changed.
- Unrestricted Resource Consumption
- Explanation: Overuse or abuse of an API endpoint possibly resulting in an outage or other issues.
- Example: Bots or scripts that are hammering an API repeatedly to gather data, or perhaps just attempting to DDOS something.
- Engineer’s Perspective: Rate limiting is your friend. API’s can be limited on a per user basis or through other means. DB queries can also have maximum timeouts set to prevent long running queries to slow down or lock up the DB on the backend. If the requests are valid, consider a solution to auto-scale or cache the largest requests if that fits the use-case.
- Broken Function Level Authorization
- Explanation: Similar to the object level authorization vulnerability, but with functions, like adding a user, or sending an email/etc.
- Example: It might be possible for a user to guess a url like example.com/api/create_user that might actually create a new user in the system. If the endpoint within your API doesn’t check first to make sure the user should have this access, they may be able to compromise the site or do other harm.
- Engineer’s Perspective: Again, anything at all that an API is exposing should be aware of the exact user making the request and have a way to control access to that request to only authorized users. Good practice may be to have a default deny-all policy in place that can only be overridden by specific allow policies on the sensitive function or route.
- Unrestricted Access to Sensitive Business Flows
- Explanation: APIs expose functions like buying a product or posting a comment, but in theory these can be abused if used in an automated way.
- Example: Someone using automation and multiple accounts to auto-bid many times on an item that they themselves intend to purchase at a high price, while having many similar items for sale. The apparent sales price of the auction item may be higher than it should be and the person sells their other items for higher than market value as a result.
- Engineer’s Perspective: Limitations should be in place for any processes that can be abused. This type of vulnerability is hard to prevent as much thought needs to go into the design of the systems beforehand with a mind to how someone might try to abuse them. In the example here, we might implement both a minimum bid % increase as well as a maximum number of bids in a given timeframe to try to limit something like this.
- Server-Side Request Forgery (SSRF)
- Explanation: An interesting issue, this can occur if your code can be tricked into making external requests to third party urls or resources.
- Example: User’s are allowed to choose which vendor for an external process used by your site, like credit card processing. However, this vendor choice shows up as a url string in the address bar at the top of the page, and in theory someone can change that string to force your systems to query a random url that might contain malware or something else.
- Engineer’s Perspective: Any user input at all needs to be properly sanitized. In our example above, making sure that the url string isnt part of an API query might be a first step, while also making sure that API can only select from fixed choices is another, preventing anything outside of allowable selections for the third party resource url. This type of vulnerability can be tricky to find, as often there are many different ways for users to add input to your site’s API endpoints. Sanitize, Sanitize, Sanitize.
- Security Misconfiguration
- Explanation: Standard stuff. Unpatched vulnerabilities and servers, unprotected system files, or misconfigured settings that could potentially allow access to protected resources.
- Engineer’s Perspective: Having tooling in place to find issues like these is key. Regularly updating servers, frameworks, code libraries, and cloud services is important. Making sure to follow security best practices for network, server, and file configurations is critical.
- Improper Inventory Management
- Explanation: Old versions of endpoints or APIs may still exist for backwards compatibility or other reasons, and attackers might find these and exploit code vulnerabilities or other issues with these outdated services.
- Engineer’s Perspective: Maintaining an inventory of all exposed services and APIs is important. Properly securing older legacy endpoints can be overlooked if teams are overworked. Always make sure to either remove older services or keep them updated to today’s security standards.
- Unsafe Consumption of APIs
- Explanation: This involves your systems interacting with data and responses from third party APIs.
- Example: your systems interact with example_api.com’s endpoints. An attacker has learned that when example_api.com has an outage, they forward their api endpoints to a custom status page that is hosted elsewhere in an insecure way. They hijack the status page and DDOS the example_api.com’s endpoints, causing your services to hit that status page. If your services directly process data from the now-down external endpoints without properly sanitizing this data, you could be exposed to an attack depending on what is returned by the new status page.
- Engineer’s Perspective: Correctly sanitize any input from an external source. You cannot trust that someone else’s API isn’t going to return a bash script or SQL command instead of the expected response. Be prepared!
Being aware of these things, of course, is only the first step. Security in most organizations is seen as an expense, until it is not. Making sure you have the time and resources needed to prevent issues like these beforehand is better than cleaning them up after the fact.