Products

Solutions

Resources

Search for API Security Tests

What are the OWASP Top 10 API Security Threats in 2023?

The OWASP Top 10 for API 2023 is the latest list released by the Open Web Application Security Project (OWASP). In this blog you will learn what are these top 10 API vulnerabilities and how to protect your APIs against them.

OWASP Top 10 API Security Threats 2023
OWASP Top 10 API Security Threats 2023
OWASP Top 10 API Security Threats 2023
Medusa Author

Medusa

6 min

OWASP API TOP 10 2023

  1. API1:2023: Broken Object Level Authorization

  2. API2:2023 - Broken Authentication

  3. API3:2023 - Broken Object Property Level Authorization

  4. API4:2023 - Unrestricted Resource Consumption

  5. API5:2023 - Broken Function Level Authorization

  6. API6:2023 - Unrestricted Access to Sensitive Business Flow

  7. API7:2023 - Server Side Request Forgery

  8. API8:2023 - Security Misconfiguration

  9. API9:2023: Improper Assets Management

  10. API10:2023 - Unsafe Consumption of APIs

API1:2023: Broken Object Level Authorization

Broken Object Level Authorization occurs when an API exposes endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Attackers can exploit these endpoints by manipulating the ID values sent in requests, allowing them to bypass authorization and perform unauthorized actions on these objects.

  • API Endpoint for Updating User Profile: HTTP Request

  • The API Endpoint is used to update user details based on the userId provided in the json body. But if the authorization checks are not enforced properly, an attacker can change the userId to any valid userId and update their personal information

PUT /api/user/profile
Authorization: Bearer <token>
Content-Type: application/json
{
  "userId": "456",   // Attacker manipulates the userId
  "username": "malicious_user",
  "email": "malicious.user@example.com",
  "role": "admin"
}

HTTP Response (Success):

PUT /api/user/profile
Authorization: Bearer <token>
Content-Type: application/json
{
  "userId": "456",   // Attacker manipulates the userId
  "username": "malicious_user",
  "email": "malicious.user@example.com",
  "role": "admin"
}

Similar to the previous request, the Authorization header contains the user's authentication token.

This is the vulnerable code for this

PUT /api/user/profile
Authorization: Bearer <token>
Content-Type: application/json
{
  "userId": "456",   // Attacker manipulates the userId
  "username": "malicious_user",
  "email": "malicious.user@example.com",
  "role": "admin"
}

In this example, the vulnerability lies in the insufficient authorization check in the /api/user/profile PUT endpoint. The server checks if the user making the request (req.body.userId) matches the authenticated user (userId) extracted from the token). However, it lacks additional checks, such as ensuring the user has the appropriate role or ownership of the resource being updated.

Another type of BOLA, known as "BOLA by parameter pollution", occurs when an attacker manipulates or injects multiple instances of the same parameter in a request. This allows them to bypass authorization checks and gain unauthorized access to resources and objects.

Visit this blog to understand how attackers manually exploit this vulnerability with prevention and how you can automate testing for this vulnerability using Akto.

How To Test BOLA by Parameter Pollution Using Akto

API2:2023 - Broken Authentication

Broken Authentication in API endpoints happens when the API fails to properly enforce authentication checks, allowing unauthorized users to gain access to sensitive data or perform privileged actions. This could involve issues such as the API not validating authentication tokens properly, or session management being improperly implemented. As a result, an attacker could impersonate other users or even gain administrative access, leading to potential data breaches and unauthorized transactions.

Some Types of Broken Authentication:

JWT None Algorithm

JWT (JSON Web Token) is a compact, URL-safe means of representing claims to be transferred between two parties. The "none" algorithm in JWT is a controversial part of the JWT specification that signifies that the integrity of the token has not been digitally signed or MACed.

In essence, the "none" algorithm means that the security of the JWT relies entirely on the transport layer, without any cryptographic protection. When a JWT with the "none" algorithm is received, it should be accepted without having to validate any signature. This could potentially lead to security vulnerabilities if the token is intercepted and tampered with during transit.

You can automate broken authentication testing from Akto's test editor.

Broken User Authentication (BUA)

CSRF By Removing CSRF Token

Cross-Site Request Forgery (CSRF) is a type of online attack that tricks the victim into submitting a malicious request. It uses the identity and privileges of the victim to perform an undesired function on their behalf.

The CSRF token is a defense mechanism used to protect against CSRF attacks. It is a unique, random value associated with a user's session and is typically included as a parameter in requests that cause a state change on the server (like changing a password). When the server receives a state-changing request, it checks the CSRF token in the request against the CSRF token associated with the session. If they match, the request is considered legitimate.

If a CSRF token is removed, the application becomes vulnerable to CSRF attacks. Without the token, the application won't be able to verify whether the state-changing request was intentionally made by the user or was initiated by a third party (the attacker). This could lead to unauthorized actions being performed on the user's behalf without their knowledge or consent.

To mitigate this vulnerability, it's essential to include CSRF tokens in all state-changing requests, and to verify the token on the server for each of these requests. Also, the application should not have any "open" endpoints that change the application state and do not require a CSRF token. If an endpoint doesn't need to protect against CSRF, it's likely that it doesn't need to cause a state change.

CSRF test by replacing with invalid csrf token - Akto

You can explore more scenarios here.

Prevention

  • Secure Passwords:

    • Enforce strong password policies for users, including the use of complex passwords and regular password updates.

  • Multi-Factor Authentication (MFA):

    • Implement multi-factor authentication to add an extra layer of security beyond just passwords.

  • Secure Session Management:

    • Use secure session management practices, including random session IDs, session timeouts, and session rotation.

  • Token-Based Authentication:

    • If applicable, consider using token-based authentication mechanisms like JWT (JSON Web Tokens) and ensure secure token storage and transmission.

API3:2023 - Broken Object Property Level Authorization

Broken Object Property Level Authorization is similar to Broken Object Level Authorization, but it occurs when an API allows unauthorized access to certain properties of an object. This can happen when an API endpoint exposes object properties without proper authorization checks, allowing attackers to manipulate these properties and perform unauthorized actions. For instance, if the API does not enforce proper authorization checks, an attacker could potentially modify properties of any object, leading to data manipulation or unauthorized actions.

Two categories are:

  1. Excessive Data Exposure

    Sensitive information that could be unnecessarily exposed by an API endpoint can include a broad range of data, depending on the context and the nature of the application. Examples of such sensitive information may include:

  • User credentials such as usernames, passwords, or authentication tokens.

  • Personal identifiable information (PII) such as full names, addresses, phone numbers, or social security numbers.

  • Confidential business data such as sales figures, strategic plans, internal communications, or proprietary technology details.

  • Financial data such as credit card numbers, bank account details, or transaction histories.

  • Health records or other sensitive personal data.

  1. Mass Assignment
    Mass Assignment is a vulnerability that occurs when an application populates the properties of an object directly from user input, without proper validation or filtering. This allows an attacker to set values they shouldn't have access to, leading to potential data manipulation or unauthorized actions.
    Check out how attackers exploit the mass assignment vulnerability with prevention and learn how to utilize Akto to automate the detection of this vulnerability.

API4:2023 - Unrestricted Resource Consumption

Unrestricted Resource Consumption, often referred to as a Denial of Service (DoS) attack, occurs when an API allows an attacker to consume resources (such as memory, CPU, or disk space) without limit, causing the system to slow down or crash. This can happen when the API doesn't implement proper rate limiting or doesn't handle large amounts of data properly, allowing an attacker to send large amounts of requests or data to overwhelm the system.

Consider an API endpoint that is responsible for file uploads. If there are no proper checks on the size or type of the file that a user can upload, an attacker can exploit this by uploading very large files or many files at once, consuming the server's resources.

Here's an example of how this could occur:

// Endpoint for uploading files
app.post('/api/file/upload', (req, res) => {
  // The uploaded file is stored in the 'file' property of req.files
  const file = req.files.file;
  // Save the file to the server
  file.mv(`/server/path/to/files/${file.name}`);
  res.json({ message: 'File uploaded successfully.' });
});


In this example, there are no checks on the size or type of the file being uploaded. An attacker could upload a very large file, or many files at once, potentially causing the server to run out of disk space or memory and slowing down or crashing the system.

Prevention

  • Rate Limiting:

    • Implement rate limiting to restrict the number of requests a user or IP address can make within a specific time frame. This prevents excessive resource consumption by limiting the frequency of API calls.

  • Validate Request:

    • Ensure the server verifies the data it receives from the body parameters returning records.

API5:2023 - Broken Function Level Authorization


Broken Function Level Authorization is a security vulnerability that occurs when an API endpoint allows unauthorized users to access functionality they should not be able to. This can happen when an API fails to properly check a user's role or permissions before allowing them to execute a function or access a resource. As a result, an unauthorized user could execute functions or access resources that they should not be able to, potentially leading to unauthorized actions or data breaches.
Read this blog to gain a deeper understanding of this vulnerability as well as prevention, and learn how to automate the detection of this vulnerability using Akto.

How to test Broken Function Level Authorization by Changing the HTTP Method Using Akto?

API6:2023 - Unrestricted Access to Sensitive Business Flow

API6:2023 - Unrestricted Access to Sensitive Business Flow refers to a security risk where an API does not enforce adequate restrictions on access to sensitive business processes. This can allow unauthorized users or systems to interact with these processes, potentially leading to unauthorized actions or data breaches. These sensitive processes could include things like user registration, data processing, or transaction handling. Without proper access controls in place, an attacker could manipulate these processes for malicious purposes.
Some examples of sensitive business flows and potential risks associated with unrestricted access:

  • Medical Records Access:

    • Vulnerability: Unrestricted access to medical records retrieval API.

    • Risk: An attacker could retrieve sensitive medical information of individuals, violating privacy laws and potentially using the information for identity theft or malicious purposes.

  • Appointment Scheduling:

    • Vulnerability: An attacker manipulates the appointment scheduling system to block all available slots.

    • Risk: This could disrupt normal business operations or services, causing inconvenience to genuine users and potentially impacting revenue.

  • Employee Salary Modification:

    • Vulnerability: Lack of proper authorization checks on an API endpoint that allows modification of employee salaries.

    • Risk: An attacker could modify the salary of any employee, leading to financial losses, demoralization among employees, and potential legal issues.

  • Document Upload and Sharing:

    • Vulnerability: Unrestricted access to document upload and sharing functionality.

    • Risk: An attacker could upload malicious files, inappropriate content, or confidential documents, impacting the reputation of the platform and potentially causing legal issues.

  • Inventory Exhaustion:

    • The attacker aims to deplete the entire stock of a particular high-demand item during a short time frame.

    • This rapid depletion prevents genuine customers from securing the product, creating a sense of urgency and scarcity.

Prevention

  • Block Tor Exit Nodes and Proxies:

    • To enhance security, consider using a Web Application Firewall (WAF) and implementing request rewrite rules. These measures can help detect and mitigate attacks, while still allowing legitimate traffic to pass through.

    • Risk: An attacker could upload malicious files, inappropriate content, or confidential documents, impacting the reputation of the platform and potentially causing legal issues.

  • Secure Access to APIs:

    • The attacker aims to deplete the entire stock of a particular high-demand item during a short time frame. This rapid depletion prevents genuine customers from securing the product, creating a sense of urgency and scarcity.

    • Recognize and pinpoint critical business flows that could pose a threat to the API if used excessively.

API7:2023 - Server Side Request Forgery

Server Side Request Forgery (SSRF) is a type of web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. In a typical SSRF attack, the attacker tricks the server into making a connection back to itself, or to another server that the attacker controls, or to an internal resource that the server can access but is not normally accessible to the attacker.

Certainly, here's a revised example considering the endpoint as an API endpoint:

Suppose we have a web application that includes an API endpoint designed to fetch an image from a user-provided URL:

Here's what the Python code for that API endpoint might look like:

from flask import Flask, request
import requests
app = Flask(__name__)
@app.route('/api/fetch_image', methods=['GET'])
def fetch_image():
    image_url = request.args.get('url')
    image = requests.get(image_url).content
    return f'Successfully fetched {image_url}'
if __name__ == '__main__':
    app.run()

In this example, the server fetches the image from the URL provided in the 'url' query parameter and returns a success message.

An attacker could exploit this by providing a URL that points to an internal resource. For example, they could provide the URL http://localhost:5000/admin as the 'url' query parameter:

GET /api/fetch_image?url=http://localhost:5000/admin HTTP/1.1
Host: vulnerable-website.com

The server would then fetch the contents from http://localhost:5000/admin and return a success message:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Successfully fetched <http://localhost:5000/admin>


In this case, the server could reveal sensitive information from the /admin path on localhost that the attacker should not have access to. This is an example of a Server Side Request Forgery (SSRF) attack.

Prevention

  • Input validation: Validate and sanitize user inputs to prevent malicious data from being used in requests.

  • Whitelist URLs: Whitelist the domains that your application uses.

  • Enable Authentication: Make sure that the authentication is enables in every service that is running in your internal system to reduce damage.

  • Use Regex: If you can't whitelist domains, you can use regex for information with a simple structure, such as a password or a zip code, to check its safety. However, for more complex data, it's advisable to use specialized tools designed for the task. This avoids the creation of intricate rules that may be difficult to manage and potentially erroneous.

  • Monitor outgoing requests: Monitor and log outgoing network requests to detect unusual or unexpected patterns that may indicate an SSRF attack.

Want the best proactive API Security product?

Our customers love us for our proactive approach and world class API Security test templates. Try Akto's test library yourself in your testing playground. Play with the default test or add your own.

Some types of SSRF

Port Scanning with SSRF

Port Scanning with Server Side Request Forgery (SSRF) refers to a security exploit where an attacker uses an SSRF vulnerability in a web application to perform a port scan of internal resources that they wouldn't normally be able to access. The attacker manipulates the server-side application to make HTTP requests to internal resources, allowing them to identify open ports and potentially uncover additional vulnerabilities.
Watch this video to understand and test for this vulnerability.

Sensitive AWS Details Exposed Due to SSRF

Server Side Request Forgery (SSRF) can lead to exposure of sensitive details from AWS (Amazon Web Services) when the application is hosted on an AWS instance. This can occur when an attacker is able to make requests to the AWS instance metadata API, which can reveal sensitive data.
The AWS instance metadata API provides data about the running instance, and this API is accessible from within the instance at http://169.254.169.254. Without proper safeguards, an attacker could use SSRF to make requests to this API, potentially gaining access to sensitive data such as IAM role credentials, security credentials, and more.

For example, an attacker could exploit an SSRF vulnerability to send a request to http://169.254.169.254/latest/meta-data/iam/security-credentials/. If the application is using an IAM role, this will return the role name. The attacker could then request http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name] to retrieve the role's access keys and token.

To mitigate this vulnerability, it is recommended to:

  • Use a firewall to block or restrict outbound traffic from your application to 169.254.169.254.

  • Regularly rotate IAM role credentials.

  • Implement SSRF protection mechanisms such as allowing only certain domains in URL parameters or using a URL allowlist.

  • Use IMDSv2 instead of IMDSv1 for all applications and instances, to adhere to latest security standards set by AWS

If you wish to automate testing for this vulnerability, consider using this test.

Sensitive AWS details exposed due to SSRF - Akto

API8:2023 - Security Misconfiguration

Security Misconfiguration refers to a security risk where an API is incorrectly configured, leaving it vulnerable to attacks. This can happen when default configurations are used, unnecessary features are enabled, or when proper security hardening measures are not taken. Misconfigurations can lead to unauthorized access or data exposure, potentially leading to data breaches or other malicious activities.

  1. Outdated Systems and Missing Patches:

  • Issue: Failure to apply the latest security patches or operating with outdated systems.

  • Implications: Leaves the system vulnerable to known exploits and increases the risk of cyberattacks.

  • Mitigation: Regularly update and patch systems to address known vulnerabilities and enhance overall security posture.

  1. Apache Config File Disclosure**:**

  • Issue: Apache configuration files are exposed due to misconfiguration.

  • Implications: This exposes sensitive information about the server's setup and security measures.

  • Mitigation: maintaining up-to-date software, enforcing strict access controls, encrypting sensitive data, and implementing regular security audits.

  1. Discrepancies in Request Processing:

  • Issue: Inconsistencies in the way incoming requests are processed across servers in the HTTP server chain.

  • Implications: May lead to data corruption, manipulation, or unauthorized access.

  • Mitigation: Ensure uniform request processing mechanisms across servers to maintain data integrity and security.

  1. Missing Transport Layer Security (TLS):

  • Issue: Absence of TLS encryption for data in transit.

  • Implications: Exposes sensitive information to eavesdropping and man-in-the-middle attacks.

  • Mitigation: Implement TLS to encrypt communication channels and safeguard data during transmission.

5. Mango Express Unauthenticated Access:

  • Issue: Mango Express is susceptible to unauthenticated access, posing a security risk.

  • Implications: Unrestricted entry allows unauthorized users to potentially exploit and compromise sensitive data.

  • Mitigation: Address by applying authentication mechanisms, restricting access to authorized users, and promptly applying software patches and updates.

6. Missing or Improper CORS Policy:

  • Issue: Absence or misconfiguration of Cross-Origin Resource Sharing (CORS) policy.

  • Implications: Can lead to unauthorized cross-origin requests, potentially exposing sensitive data.

  • Mitigation: Implement and configure CORS policies appropriately to control cross-origin access.

7. Exposing Sensitive Information in Error Messages:

  • Issue: Error messages include stack traces or reveal sensitive information.

  • Implications: Facilitates information disclosure attacks and aids potential attackers.

  • Mitigation: Customize error messages, avoiding the inclusion of sensitive details, and log errors securely.

Test your APIs for Security Misconfiguration (SM)

API9:2023: Improper Assets Management

Improper assets management occurs when an API does not have a proper inventory of all its assets, including the various versions of the API that are deployed and the servers where they are hosted. This can lead to several security issues, such as unauthorized access to old, unpatched versions of the API, or the exposure of sensitive information through forgotten debug endpoints.
In a real-life scenario, suppose a company has multiple versions of an API, each with different endpoints. Over time, the company may phase out older versions of the API, but forget to remove them from their servers. An attacker could exploit these forgotten APIs to gain unauthorized access or expose sensitive data.
Preventing improper assets management involves having a robust API inventory management system in place. This includes:

  • Keeping track of all API versions and their respective endpoints.

  • Regularly auditing the API inventory to remove unused or deprecated APIs.

  • Ensuring proper access controls are in place for all APIs, regardless of their development stage.

  • Implementing automated tools like Akto to discover and catalog APIs.

API10:2023 - Unsafe Consumption of APIs

Unsafe Consumption of APIs refers to the security risk when a client application does not properly validate, filter, or process the responses it receives from an API. This can lead to many security issues, such as the execution of malicious code from an API response, or the exposure of sensitive data to unauthorized parties.
For example, if a client application blindly trusts an API response that includes executable code, it could lead to a Cross-Site Scripting (XSS) attack if the code is embedded into a web page without proper sanitization. Similarly, if the API response includes sensitive data that is not properly protected, an attacker could intercept the data during transmission or extract it from the client's storage.
To prevent unsafe consumption of APIs, client applications should:

  • Always validate and sanitize API responses before processing them. This includes checking for proper data types, lengths, formats, and values.

  • Never trust API responses that include executable code. If code execution is required, use secure methods such as Content Security Policy (CSP) to restrict where code can be loaded from.

  • Always use secure transmission methods, such as HTTPS, to protect data in transit from eavesdropping or Man-in-the-Middle (MitM) attacks.

  • Store sensitive data securely, using proper encryption methods and secure storage locations.

  • Regularly update and patch the client application to protect against known vulnerabilities.

Conclusion

In conclusion, the OWASP Top 10 API Security Threats for 2023 is a crucial guideline for any organization that develops or uses APIs. Each of the ten threats outlined presents a significant risk to data security and must be diligently addressed. By understanding these threats, implementing appropriate mitigations, and maintaining a proactive approach to security, organizations can protect their APIs and ensure the secure handling of sensitive data.

Share this post

Share this post

Share this post

Monthly product updates in your inbox. No spam.

Table of contents