OWASP 2023 Top 10 Explained
Published: May 8, 2024
What is OWASP?
OWASP is the “Open Web Application Security Project.” It is a non-profit organization that focuses on improving the security of software. OWASP’s mission is to provide resources, tools, and best practices to help organizations develop, deploy, and maintain secure web applications and web services.
Periodically, OWASP releases a series of guidelines related to the most common types of security exploits that attackers are taking advantage of. Traditionally these have been focused on web application security, but in 2019 OWASP for the first time released a set of security exploits focused on API attacks, which is the topic of today’s post. In 2022, the OWASP guidelines were refreshed with the latest top ten attacks. These are a must-read for anyone who is responsible for deploying or maintaining API endpoints. They focus on the top ten API threats based on risk and impact and include both examples of exploits as well as OWASP’s recommendations for mitigating vulnerability to those exploits. This makes API-focused security a relatively recent area of concern for security practitioners. In fact, APIs were only recently declared to be the most common attack surface for software.
Should I Be Concerned About My APIs?
If your software, cloud servers, or applications expose APIs to the Internet, you should probably be familiar with what data you are exposing and how it’s being protected. While you may not have control over many of those endpoints, if you are responsible for creating them, OWASP proposes that you make every effort to keep the consumers of those endpoints safe.
As a general rule, the two most effective ways to keep your APIs safe from the majority of the exploits in this year’s OWASP top ten API attack list are proper implementation and thorough testing. Nearly all the mitigations listed below generally fit into one of these two categories. Often developers take shortcuts or make assumptions that inherently expose security vulnerabilities. Let’s look at a few examples of these vulnerabilities and examine how using a combination of OWASP-recommended best practices, comprehensive logging, and leveraging tools like Splunk they can be avoided.
Vulnerability: Authentication and Authorization
At the most basic level, OWASP suggests that any API should have some sort of authentication to confirm that the consumer who is requesting the resource is in fact who or what they claim to be. An issue can arise when developers assume that once the user has been authenticated, they will responsibly access only those endpoints to which they have been directed. For example, if a legitimate user logs into a website and an API call fetches their customer information for display purposes, can that user then alter the API call to retrieve a different customer’s information? Could they access information to which they shouldn’t have permission? Could they even alter a different customer’s data?
As OWASP’s recommendations describe, each of these scenarios can be mitigated by adding an authorization step to every method that accesses secure information. In addition, the scope of the access should also be specifically defined and confirmed. This is an example of using a Zero-trust Framework, assuming that every interaction is coming from an unknown source. Executing and testing properly enforced coding standards from the OWASP guidelines will prevent these sorts of attacks and is generally a good practice for any API development.
Ingesting comprehensive logs into Splunk will allow you to correlate whether users are accessing endpoints to which they shouldn’t have access and if a breach is detected, you can tell specifically which consumers and data were affected. These breaches will not necessarily trigger an error in your logs. For example, in the circumstance where a valid user is accessing an insecure endpoint, a generic analysis of the traffic will not show any anomalies. However, if you search specifically for endpoints that have been accessed without any kind of credentials, vulnerable endpoints can be identified.
Vulnerability: Unrestricted Access to Resources
Assuming that a user can legitimately access a resource, OWASP describes how some APIs should be defined with a reasonable standard for how often a verified account can access it and under which circumstances. The most basic example of this is when a user repeatedly calls an endpoint so that resources are entirely consumed preventing others from accessing any resources, otherwise known as a denial of service (DoS) attack. This vulnerability could also include a user monopolizing a finite resource such as concert tickets or flights.
Determining reasonable traffic patterns should be part of the development process as OWASP outlines and should be mitigated at several levels. DoS attacks should be caught well before reaching the API level, usually by a firewall or load-balancing mechanism. Modern attacks can be cleverly orchestrated to bypass those first-line defenses so OWASP recommends that additional protection should be in place to prevent these exploits at the API level using a well-configured gateway such as Kong.
Detecting these sorts of attacks with a tool like Splunk can be as simple as monitoring regular traffic patterns to identify anomalies. Determining how best to break down those statistics is dependent on the organization. For example, some APIs may have natural spikes in traffic during particular times of year: holidays, back-to-school, or special events. Other APIs may have regular traffic from a specific set of users or locations in which case access from outside these norms should be treated as suspicious. This is where Machine Learning can be leveraged to differentiate normal traffic from out-of-the-ordinary traffic.
Vulnerability: Server-side Forgery
Server-side attacks are more sophisticated but work in a similar fashion to authentication attacks. In this case, however, attackers leverage vulnerabilities on the server side by manipulating callback URLs or other parameters that are explicitly passed directly to the API. The OWASP top ten explains how the most effective way to mitigate this exploit is to perform strict validation for all parameters that are passed in the API call. This not only includes values but also the list of allowed parameters as well. Any attempts to pass in additional parameters or values outside of an expected range should not return results.
Once again, verbose logging can help to identify these attacks even when no errors are present in the logs. Tracking which parameters or headers are included in each call, even when data is not included, can identify nefarious calls or attempts to bypass security even when the user is known and authenticated.
Vulnerability: Security Misconfiguration
OWASP stresses that it is crucially important for API developers to ensure that the environments on which their code is running is up-to-date with the latest security updates and patches. Code should also follow current industry best practices to mitigate attacks including, for example: using TLS where appropriate, implementing proper CORS (cross-origin resource sharing) policies, and not exposing sensitive information through overly verbose error messages
Ingesting logs into Splunk from build pipelines, such as Jenkins services, can also be a great place to pull together reporting on the software included in a build or deployment which can help identify out-of-date dependencies.
Vulnerability: Poor API Governance Policies
As developers produce new versions of their APIs, procedures should be put in place to remove prior versions and documentation should be clear about what features have been implemented or removed. OWASP suggests that leaving unmaintained APIs accessible can provide attackers with ways to bypass security on newly-secured endpoints.
In addition to proper configuration, OWASP recommends adding a version stamp to API routes or services which can help to identify unpatched vulnerabilities or potential backdoors that could be exploited by making valid calls to old, non-deprecated endpoints which could include security risks.
Vulnerability: Unsafe Consumption of APIs
Some developers lower their APIs’ security standards in situations where, for example, a call is coming from a particular trusted vendor. In these cases, they may not validate input parameters, may follow redirects without validating their target, or might not properly rate-limit calls to the endpoint. As OWASP states, proper coding practices should always be followed regardless of who is consuming the API.
This, once again, highlights the importance of verbose logging practices to ensure both security and availability. Relying on reported errors for security is only half the job. Many contemporary attacks are sufficiently sophisticated to avoid raising errors until it’s too late. Following OWASP recommendations is essential to mitigating these types of attacks.
Practical OWASP
Thinking about API security from an attacker’s perspective is a good first step to mitigating vulnerabilities. OWASP’s top ten vulnerabilities will help you to identify security risks at all levels of your APIs development, from gateway to ingress to service to the source code and even the machines running your code. Your work isn’t over once the attack vectors are identified. In addition to creating Splunk dashboards to monitor some of the vulnerabilities above, OWASP recommends you create automated tests that are performed regularly to ensure that any changes introduced into your environment don’t inadvertently expose new vectors. Up-to-date test environments, source control with CI/CD, and a well-trained development team are other critical ways by which you can keep your APIs secure as recommended by OWASP.
Conclusion
No API environment is ever 100% safe from all attacks. It’s no coincidence that the act of deploying an API is referred to as ‘exposing’ it since APIs by definition expose your organization to anyone who can reach it – in many cases, this is the entire world. As OWASP recommends, keeping that exposure safe should be among your organization’s top priorities.
A common thread among all the OWASP top ten vulnerabilities discussed in this article is that proper security standards should always be followed and those can be verified through comprehensive testing policies. It’s the responsibility of your development team to keep your organization safe by ensuring that APIs are consumed securely and responsibly. For more detailed information about how to protect your organization against API attacks and to understand how to leverage OWASP’s top ten list to improve your software development practices to this end, please download Solsys’ API security ebook here: https://solsys.ca/api-ebook/
