OWASP Top 10 API Security and Remediation
Why APIs?
Monolithic applications have driven businesses for longer periods of time, but the application started becoming complex and resistance of critical business domains to even small downtime, paved the way for applications to become distributed. Consider mammoth size projects where varied small application parts like in-house, some off the shelf, and some open source have to work in tandem to keep the application up and running. But, what glues these applications together and helps them communicate among themselves as well as other components like databases and web services? These are APIs that act as an orchestrator so that all the components of the project work seamlessly with each other. APIs are a critical part of modern web and mobile applications. They allow applications to communicate with each other and share data. But, their capability to access data has made them a perfect choice for hackers as the APIs can be intercepted and the data can be exploited if API security has not been taken care of.
Which are the Top 10 OWASP Vulnerabilities for APIs?
API Security is the part of Application Security. Gartner predicts that by 2025, more than 50% of data theft will be due to insecure APIs. The OWASP or Open Worldwide Application Security Project has published a list of the Top 10 API Security risks that one has to address to safeguard the APIs from exploitation.
Let’s understand the OWASP API Top 10 Vulnerabilities and a few remediations that can help to protect the APIs from the vulnerabilities.
- Broken Object Level Authorization (BOLA): Object level authorization is an access control mechanism used to validate that a user can only have access to the permitted objects. One of the most famous examples of BOLA vulnerability is the Equifax data breach, where hackers exploited a BOLA (Broken Object Level Authorization) vulnerability to access sensitive information of over 143 million customers. The attackers found a vulnerability in the application’s dispute portal, allowing them to access other customers’ dispute documents.
What care one should take?
There should be well-defined Object-level access policies in place. The object-level access to the users should be implemented in a Least Privilege manner. The users should be granted only a minimum level of access necessary to perform their tasks.
- Broken Authentication
Broken authentication is used by the attackers to impersonate legitimate users
online. Broken authentication can be the result of improper session management and/or credential management.
How can it be avoided?
To safeguard the APIs from Broken authentication, one can use WAF to validate sessions. Use of Multifactor Authentication is encouraged. Limiting session time and implementing proper session Timeouts will also help.
- Broken Object Property Level Authorization:
It is not necessary that all the users should have access to all the properties in the object. Broken Object Property Level Authorization vulnerabilities occur when authorization isn’t performed at a granular level. Attackers can take advantage of these vulnerabilities to access or alter properties maliciously.
The Workaround?
The issue can be addressed with robust access mechanism. The access mechanism should be such that not all the data in an object is accessible to all the users. The only relevant data properties can be made accessible to users.
- Unrestricted Resource Consumption:
API requests require resources such as network bandwidth, CPU, memory, and storage. APIs may have access to resources such as emails/SMS/phone calls or biometrics . If the attackers get access to these end points it may lead to overconsumption of resources and may lead to DoS.
Care to be taken
Proper limits should be set for the resource consumption in APIs. Techniques such as rate limiting and throttle controls for APIs can streamline the API usage and in turn resource utilization.
- Broken Function Level Authorization :
There has to be a clear separation between administrative and regular functions in the code. If the attackers gain access to other users’ resources and/or administrative functions , they may exploit the API functionality to twist them for malicious use.
How can it be avoided?
Keep proper segregation between the functions accessible to the user and the administrator. The function meant for administrative use should not be accessible to the other users.
- Unrestricted Access to Sensitive Business Flows :
With APIs, there is a risk of exposing the critical workflow to unwanted users. The workflow may handle some critical business parts or involve access to payment-related mechanism. If the APIs are compromised and targeted using bots the impact will be even larger.
The work around
We can’t stop APIs from talking to various other APIs and different business units. One has to make sure that the different endpoints of API and its handshaking with different business logic is also secure. Using Captcha can avoid bot-initiated attacks.
- Server Side Request Forgery:
The resources like file systems are well protected behind the firewalls and there is less chance of someone getting access to them bypassing the firewall. The web servers and cloud services in that case may pave a way to unauthorized access to these resources as they are whitelisted in the firewall settings.
Can it be avoided?
Use of allowlisting and denylisting in APIs, and servers can help to restrict the incoming requests for legitimate traffic.
- Security Misconfiguration:
Developers may knowingly or unknowingly disable the security features or sometimes may get misconfigured leaving APIs susceptible to vulnerabilities.
Any Workaround?
Make sure the security configurations are configured correctively. Don’t allow over permissions on the resources like cloud. Make sure the security measures suggested by the framework is followed. Update software regularly.
- Improper Inventory Management:
When a new version of the API is hosted, the usage of the older API may continue for some months but there has to be a proper de-commissioning process in place that will detach older API from the workflow. If the older version of APIs has access to the workflow and resources, the system is still vulnerable to exploitation.
Care to be Taken
Making sure the correct and safe version of the API is used. While applying security measures to the APIs make sure the same measures are applied to older versions of APIs under use.
- Unsafe Consumption of APIs :
Developers tend to trust data received from third-party APIs and adopt weaker security standards. The attackers target less secured third-party APIs than the native APIs. Here the third-party APIs become a gateway to the targeted API.
The Workaround
If the APIs are using some third-party APIs , make sure that the data coming from the third party API is safe and not compromised to any vulnerability.
Conclusion
APIs have become de facto components of the software as they act as an adhesive that stitches different pieces of the software together. But, if these APIs are not secured they may pave the way to the attackers to intrude into the system and exploit it. As predicted by the Gartner, more than 50% of data theft will be due to unsecure APIs by 2025. The OWASP has already published the top 10 API security threats that one should be aware of to safeguard the business flow from the vulnerabilities percolating from the APIs. One has to plan and implement different remediations, best practices, security policies, and tools to safeguard the APIs and the business in turn.
By Sonal Kakar.