source

1. Broken Object Level Authorization (BOLA)

Description: API users should only be able to access resources that belong to them. When BOLA occurs, users may be able to access resources that don’t belong to them.

Example:
If an API lets users view their personal information, an attacker might modify the URL from /user/123 to /user/124 to access another user’s information.

How to Test:
Modify the object identifier in the request URL and check if you can access other users’ data. If unauthorized access is possible, it indicates a BOLA vulnerability.

2. Broken Authentication

Description: This occurs when an API’s authentication mechanisms are weak or poorly implemented, allowing attackers to bypass them.

Example:
A simple username and password-based login system without multi-factor authentication may allow an attacker to guess passwords and gain unauthorized access.

How to Test:
Attempt to log in with weak passwords or use brute force attacks. Check whether the API enforces strong password policies and multi-factor authentication.

3. Broken Object Property Level Authorization

Description: This vulnerability occurs when an API allows users to access properties of an object that they shouldn’t be able to.

Example:
An API that lets users view their profiles could have a flaw where users can modify parameters in the request (like ?include_salary=true) to access others’ sensitive information, such as salary.

How to Test:
Test by modifying request parameters to access unauthorized object properties. Ensure sensitive data like salary or private emails cannot be accessed without proper authorization.

4. Unrestricted Resource Consumption

Description: APIs may lack resource consumption limits, allowing attackers to overwhelm the system, causing denial of service or service degradation.

Example:
Uploading large files, like a 100MB video, could consume server resources, leading to downtime or slower responses for legitimate users.

How to Test:
Upload large files or send numerous requests in a short time and check whether the API enforces proper limits on file size or request frequency.

5. Broken Function Level Authorization

Description: This flaw occurs when an API allows users to access functions they are not authorized to use.

Example:
An API may allow regular users to call administrative functions like deleting or modifying data that only admins should have access to.

How to Test:
Attempt to access restricted functions by modifying the request or using a lower privilege account. If the system does not enforce proper function-level authorization, it is vulnerable.

6. Unrestricted Access to Sensitive Business Flows

Description: APIs that expose sensitive business processes, like payment or financial transactions, should have strict access controls. If these processes are improperly protected, unauthorized users may execute actions they shouldn’t.

Example:
An attacker could call a payment API directly to make unauthorized payments if proper authentication and access controls are missing.

How to Test:
Test by attempting to execute sensitive business operations (like payments or transfers) without proper authorization. Verify that only authorized users can access these flows.

7. Server Side Request Forgery (SSRF)

Description: SSRF vulnerabilities allow attackers to send requests from the server to internal or external resources that they shouldn’t be able to access.

Example:
An API that accepts a URL parameter might allow an attacker to input an internal service URL (e.g., http://internal-api.local), potentially exposing sensitive internal systems.

How to Test:
Use tools like Burp Collaborator to inject internal or malicious URLs into the API requests and check if the server accesses them. If it does, SSRF is a vulnerability.

8. Security Misconfiguration

Description: Security misconfigurations occur when an API is improperly set up, leading to vulnerabilities such as exposing sensitive information in error messages or unnecessarily open ports.

Example:
An API might expose detailed error messages that include stack traces, which attackers can use to identify vulnerabilities in the system.

How to Test:
Scan the API for unnecessary open ports, exposed debugging information, or detailed error messages that can reveal sensitive information.

9. Improper Inventory Management

Description: APIs might expose old or unused endpoints that can be exploited by attackers if not properly managed.

Example:
An outdated API endpoint might still be active, even though the service no longer uses it. Attackers could exploit it to gain unauthorized access or retrieve sensitive data.

How to Test:
Check for unused, outdated, or hidden API endpoints that may still be accessible. Verify if the API properly removes or disables old endpoints.

10. Unsafe Consumption of APIs

Description: APIs that fail to properly validate user input are vulnerable to attacks like SQL injection or cross-site scripting (XSS).

Example:
An API that allows users to submit text input might fail to sanitize the input, allowing an attacker to inject malicious code, such as <script>alert("XSS")</script>.

How to Test:
Inject malicious scripts or SQL commands into input fields and observe whether the API performs proper input validation. If malicious code is executed, the API is vulnerable.

Let’s assume we are testing an e-commerce API that handles user profiles, payment transactions, and inventory management. Our goal is to assess the security posture of the API using various tools and techniques.

1. Broken Object Level Authorization (BOLA)

Vulnerability: Users can access resources they shouldn’t.

Simulated Scenario: We’re testing whether a user can access the profile data of other users by modifying the user_id in the API endpoint.

API Endpoint:
GET /user/{user_id}

Testing Process:

1. Tool: Postman or Burp Suite
2. Command:
   • First, log in as user123 and retrieve the profile:
     GET /user/123
   • Now, try changing the user_id parameter to 124 to see if you can access another user’s profile:
     GET /user/124
3. Observation: If you are able to access user 124‘s data without proper authorization, the API has a BOLA vulnerability.

Tooling:

• Burp Suite: Use Burp Suite’s “Repeater” to modify the user_id and test different user IDs.
• Postman: Manually change the user_id parameter in the request.

2. Broken Authentication

Vulnerability: Weak authentication mechanisms allow attackers to bypass security.

Simulated Scenario: We will check if the API allows weak password authentication or if brute force can bypass login.

API Endpoint:
POST /login

Testing Process:

1. Tool: Hydra (for brute force), Burp Suite
2. Command:
   • Use Burp Suite to intercept the login request and try to submit incorrect login credentials.
   • Alternatively, use Hydra for brute-force testing:
     hydra -l admin -P /path/to/password-list http://localhost:8080 login
3. Observation: If you can successfully authenticate with weak credentials, the API is vulnerable to brute-force or weak password attacks.

Tooling:

• Hydra: A fast password-cracking tool.
• Burp Suite: Use the Intruder tab for brute-force login attempts.

3. Broken Object Property Level Authorization

Vulnerability: Unauthorized users can access sensitive properties of objects.

Simulated Scenario: A user tries to access the salary field of a profile object that they shouldn’t be able to.

API Endpoint:
GET /profile/{user_id}

Testing Process:

1. Tool: Postman or Burp Suite
2. Command:
   • Retrieve the profile details for user 123:
     GET /profile/123
   • Attempt to access a hidden or restricted property like salary:
     GET /profile/123?include_salary=true
3. Observation: If the response includes sensitive information like salary, the API lacks proper property-level authorization checks.

Tooling:

• Postman: Modify the parameters and check if sensitive data can be exposed.
• Burp Suite: Intercept requests to modify query parameters.

4. Unrestricted Resource Consumption

Vulnerability: No resource consumption limits in place, causing potential denial of service (DoS).

Simulated Scenario: We attempt to upload large files to see if the API imposes any size restrictions.

API Endpoint:
POST /upload

Testing Process:

1. Tool: Postman
2. Command:
   • Try uploading large files using Postman:
     POST /upload
     Attach a 100MB or larger file to the request.
3. Observation: If the API does not impose a file size limit, it is vulnerable to resource exhaustion (e.g., denial of service).

Tooling:

• Postman: Use Postman to upload large files and check if the API rejects files that exceed certain sizes.

5. Broken Function Level Authorization

Vulnerability: Users can access functions they are not authorized to.

Simulated Scenario: We test whether a regular user can access admin functions like deleting an order.

API Endpoint:
DELETE /order/{order_id}

Testing Process:

1. Tool: Postman
2. Command:
   • First, test with a regular user (non-admin) to see if they can delete an order:
     DELETE /order/999
3. Observation: If the regular user is able to delete an order without proper authorization, there is a broken function-level authorization.

Tooling:

• Postman: Send DELETE requests as a regular user to access admin-only functions.

6. Unrestricted Access to Sensitive Business Flows

Vulnerability: Unauthorized users can trigger sensitive business operations, like payments.

Simulated Scenario: We test whether a user can make unauthorized payments through the API.

API Endpoint:
POST /payment

Testing Process:

1. Tool: Postman
2. Command:
   • Make a payment request without proper authorization (as a non-logged-in user):
     POST /payment
     Include payment details in the body (amount, recipient).
3. Observation: If the API allows a non-authenticated or unauthorized user to make a payment, it has a vulnerability.

Tooling:

• Postman: Manually test for unauthorized access to sensitive business operations.

7. Server Side Request Forgery (SSRF)

Vulnerability: An attacker can cause the server to make unauthorized requests.

Simulated Scenario: We will test if the API allows SSRF by submitting a URL that points to an internal resource.

API Endpoint:
GET /fetch

Testing Process:

1. Tool: Burp Suite or Postman
2. Command:
   • Submit a request with an internal URL:
     GET /fetch?url=http://localhost:8080/internal
3. Observation: If the API fetches internal resources (e.g., database servers, metadata services), it is vulnerable to SSRF.

Tooling:

• Burp Suite: Modify the request to include malicious internal URLs.
• Postman: Test for SSRF by submitting requests that point to internal services.

8. Security Misconfiguration

Vulnerability: Poor API configuration exposes sensitive data or vulnerabilities.

Simulated Scenario: We check if the API exposes unnecessary information, such as debug data.

API Endpoint:
GET /error

Testing Process:

1. Tool: Burp Suite or any network scanner
2. Command:
   • Trigger an error on the server:
     GET /error
     Check the response for error details or stack traces.
3. Observation: If sensitive information (like stack traces or internal system details) is exposed, the API is misconfigured.

Tooling:

• Burp Suite: Intercept the error messages to analyze the responses.
• Network Scanner: Check for exposed open ports or services.

9. Improper Inventory Management

Vulnerability: The API exposes old or unused endpoints that can be exploited.

Simulated Scenario: We attempt to access deprecated or hidden API endpoints.

API Endpoint:
GET /old-api-endpoint

Testing Process:

1. Tool: Burp Suite, Postman
2. Command:
   • Try accessing deprecated API endpoints:
     GET /old-api-endpoint
3. Observation: If the API exposes deprecated endpoints, it could lead to security issues. Ensure old or unused endpoints are disabled.

Tooling:

• Burp Suite: Use the “Spider” tool to discover hidden or unused endpoints.
• Postman: Manually test for deprecated API versions.

10. Unsafe Consumption of APIs

Vulnerability: Failure to properly sanitize user inputs, leading to SQL injection or XSS attacks.

Simulated Scenario: We test whether the API is vulnerable to XSS or SQL injection attacks.

API Endpoint:
GET /search

Testing Process:

1. Tool: Burp Suite, SQLMap, or Postman
2. Command:
   • Test for SQL injection:
     GET /search?query=' OR 1=1 --
   • Test for XSS:
     GET /search?query=<script>alert("XSS")</script>
3. Observation: If the API executes malicious code or query manipulation, it is vulnerable to SQL injection or XSS.

Tooling:

• SQLMap: Automate SQL injection testing.
• Postman: Inject XSS payloads.
• Burp Suite: Intercept and modify inputs to test for injection flaws.