Stay up to date
Stay up to date with the latest threat reports, articles & mistakes to avoid.
Simple, yet important content.
No salesy pitches and all that, promise!
What is OWASP API Top 10?
The OWASP, stands for The Open Web Application Security Project, is a non-profit foundation that works to improve application security for software. Through community-led projects globally, it is a great source for tools, resources, education & training for developers and technologists to secure the web and mobile applications.
OWASP API (Application Programming Interface) security is a project aimed at helping organisations from deploying insecure APIs. APIs are fundamental components of today’s app-driven internet life. Whether it’s banks, online retailers, transportation or consumer services, APIs are a critical part of modern SaaS, mobile and cloud technologies infrastructure. APIs are the most common ways today defining how microservices and containers communicate like systems, applications and other entities.
If new software (mobile computing, cloud computing) is affecting the world, API security is affecting this software.
Let’s look at the OWASP Top ten list of API security vulnerabilities:
- Broken Object Level Authorization
- Broken User Authentication
- Excessive data exposure
- Lack of resources and rate limiting
- Broken Function Level Authorization
- Mass assignment
- Security misconfiguration
- Improper assets management
- Insufficient logging and monitoring
This article presents each of these API vulnerabilities with attack examples and measures around how to prevent these attacks.
Broken object level authorization
This attack, also known as Insecure Direct Object Reference (IDOR) vulnerability, is amongst the topmost API security risks. Improper access controls for assets accessible from the internet make it an easy target for threat actors. This is largely due to the lack of strict authorisation controls implementation or no authorisation controls. This issue impacts in varied ways, from data disclosure to full account takeover.
For example, an API call with parameters using value (ID) associated with the resource i.e., /customers/user/john/profile.
A threat actor attempts different usernames guessing through correct accounts /customers/user/lisa/profile, /customers/user/peter/profile and so on.
API in this case did not check current user permissions and allowed the call through. Based on the user permissions, the resulting access would relate to horizontal or vertical privilege escalation vulnerability.
How to prevent broken object level authorization?
A stricter access control policy coupled with the use of random and unpredictable user ID values that are hard to guess.
Broken user authentication
Insecure or missing protection mechanisms for API endpoints causes broken user authentication flaws. Due to the way authentication mechanisms work, an authentication endpoint being always exposed makes it an attractive target for cyber criminals. Threat actors can exploit this vulnerability to steal sensitive data, take over accounts, or impersonate users.
How to prevent broken user authentication?
Implement stricter protection including but not limited to factors such as strong credential encryption, failed login attempts limit, authentication token validation. OAuth has been the de facto standard for securing APIs for both authentication and authorization mechanisms. For Java, using encrypted JWT tokens ensures identity and user characteristics are not easily susceptible to attacks.
Excessive data exposure
APIs disclose varied types of data based on the who is requesting. This purpose of what information will be served, and to whom this will be served are the core concepts while designing an API. Insecure implementation or lack of implementation of data filtering leads to disclosing more than required information. Data exposure issues are a common sight, ranging from technology or version information disclosure to high-risk issues related to user preferences or account information.
How to prevent?
Threat model the information based on how data flows from the endpoints to the client and vice versa and review the data filtering. Never process user input on the server-side without any validation.
Lack of resources and rate limiting
Threat actors can easily abuse an API leading it to consume available resources and making the service unavailable to legitimate users. This could lead to Denial of Service (DoS) attacks.
Public APIs are often the target as common misconception that there is no authentication removes risks to the application applies commonly. This is also an issue that could be exploited using multiple attack vectors such as brute force attacks, credential stuffing attacks, user enumeration, or other fuzzing techniques. Bots and other automated techniques could end up using the victim’s precious computing resources.
How to prevent?
Implement size and rate limits such as number of items to be required in a single API request, or maximum number of records that can be retrieved.
Broken function level authorization
Deploying unique strategies for different services yields complexity, that leads to vulnerabilities or increased attack surface. Every API function call should require authorization to verify that the user requesting the data is authorized to send the request on those objects. This flaw is used by threat actors to find administrative functions that may be hidden otherwise and allow access to higher privilege functions.
How to prevent?
Keep it simple. Deploy a standard approach to authorize client requests and avoid function-level authorization. Deny all access by default, and allow explicitly.
Mass assignment issue occurs where the lack of properties filtering allows exposure of internal variables or objects. Due to lack of restrictions, an endpoint may provide access to other properties outside the authorized scope allowing a threat actor to modify objects related to those parameters. This also illustrates how direct mapping client inputs to internal variables can be exploited by unauthorised users.
How to prevent?
Define properties that a client can access and avoid direct mapping of client inputs to internal variables or object names.
A security misconfiguration is a control that adds to a secure configuration but hasn’t been implemented. Secure misconfiguration is a wide topic, and flaws under this category could relate to lack of patch deployment, insecure Transport Layer Security encryption configuration, default configuration with no or weak authentication, missing security headers, verbose error messages and related issues.
How to prevent?
Perform regular penetration testing of your web application and API. Perform regular secure hardening reviews against the hosting server.
Similar to web application injection attacks, all injections i.e., OS Command injection, SQL, NoSQL, LDAP injections are part of this issue. Due to the lack of strict input validation on the server-side, malicious input can make way as a query or command to enumerate backend information.
How to prevent Injection attacks?
The core concept behind injection flaws is the lack of input validation and sanitisation of data used by the application. Any input request that contains parameters as input can be vulnerable to a code injection flaw. This could be an OS code injection, SQL injection or simple script injection based on the underlying code of vulnerable function in use.
To protect web applications against SQL injection attacks, it is important to separate data from commands and queries. Use of prepared statements (with parameterised queries) is how developers should write database queries. This allows to first define all the SQL code and then pass each parameter to the query, therefore, distinguishing between code and data irrespective of user input (malicious or legit).
Improper assets management
Just like other assets in a business, APIs go through a lifecycle and lack of asset management is related to legacy security vulnerabilities. By not retiring older versions, APIs expose more endpoints, exposing endpoints that are no more needed, not known or forgotten by the teams. This increases attack surface due to older and newer API versions running alongside.
How to prevent?
Documentation is an important step towards maintaining assets information. There should be clear segregation at the user, network and functional level between production and non-production environments. Review and retire older versions that are no more required.
Insufficient logging and monitoring
Logging and monitoring of data is a vital step for audit trails and incident response teams. Due to the lack of logging and monitoring controls, a threat actor finding difficult to attack the victim API has more time by his side, that may lead to bigger and high impact attack. This can be easily avoided by logging and analysing the suspicious events early in the attack chain due to stricter monitoring processes. Unfortunately, this is one of the reasons data breaches go unnoticed early in the attack stage.
How to prevent?
Review and ensure all necessary log levels are in place for all API endpoints. Deploy a monitoring solution to continuously monitor logs for APIs and infrastructure. Ensure that incident response process is defined and shared with teams to be prepared for any eventuality.
As can be seen above, while a few issues are common to the OWASP Top 10 application security risks, APIs are an opportunity for threat actors leading to sensitive data. API penetration testing is one of our offerings under web application penetration testing services. Our team of skilled security experts with proven industry experience ensure comprehensive coverage for web application risks, especially issues such as business logic flaws, business contexts that are often missed by automated scanners or less experienced consultants. Get in touch if we can help with your security concerns.