API Security Testing Against the OWASP API Top 10: A Hands-On Guide

APIs have replaced web pages as the primary interface between systems. Mobile apps, SPAs, microservices, partner integrations — they all communicate through APIs. And because APIs expose application logic directly, without the protective layer of a rendered UI, they present a fundamentally different attack surface than traditional web applications.

The OWASP API Security Top 10 captures the most critical risks specific to APIs. Testing against this list is not optional if your application exposes any kind of API.

API1: Broken Object Level Authorization (BOLA)

BOLA is the most common API vulnerability, and it is devastatingly simple. An API endpoint accepts an object ID as a parameter, and the backend does not verify that the authenticated user has permission to access that specific object.

How to test it:

1. Authenticate as User A and access their resources (e.g., GET /api/orders/1234)
2. Note the object IDs
3. Authenticate as User B
4. Attempt to access User A's resources using the same IDs
5. If User B can see User A's data, you have BOLA

The test is straightforward, but doing it at scale requires automation. For every endpoint that accepts an ID parameter, you need to test cross-user access. Tools like Burp Suite's Autorize extension automate this by replaying requests with different session tokens.

What to look for: Any endpoint where changing an object ID returns data belonging to a different user or organization. Pay special attention to GUIDs and UUIDs — teams sometimes assume these are unguessable and skip authorization checks.

API2: Broken Authentication

API authentication failures go beyond weak passwords. Common issues include:

• JWT tokens that are not validated properly (accepting alg: none, not verifying the signature, accepting expired tokens)
• API keys transmitted in URLs where they end up in server logs
• No rate limiting on authentication endpoints, enabling brute force
• Tokens that never expire or have excessively long lifetimes

How to test it:

• Modify JWT payloads and check if the server validates the signature
• Send requests without authentication tokens and see what returns
• Test token expiration by using old tokens
• Attempt credential stuffing against login endpoints
• Check if API keys appear in client-side code or public repositories

API3: Broken Object Property Level Authorization

This is about exposing more data than the user should see, or accepting modifications to fields the user should not be able to change.

How to test it:

• Compare API responses with the UI. If the API returns fields the UI does not display (internal IDs, email addresses, roles), the API is over-exposing data.
• Send update requests with additional fields. If PUT /api/users/me accepts a role field and changes your role to admin, that is a critical finding.
• Check for mass assignment vulnerabilities by including unexpected properties in POST and PUT requests.

API4: Unrestricted Resource Consumption

APIs that do not limit resource consumption are vulnerable to denial of service and excessive data harvesting.

How to test it:

• Send requests with large pagination values (?limit=999999)
• Upload oversized files
• Send deeply nested JSON or GraphQL queries
• Make rapid concurrent requests to check for rate limiting
• Request resource-intensive operations (complex searches, large reports) repeatedly

For GraphQL specifically, test query depth and complexity. A query that joins 10 nested relationships can bring a server to its knees.

API5: Broken Function Level Authorization

Different from BOLA, this is about accessing functions you should not have permission to use. A regular user accessing admin endpoints, a read-only user accessing write operations.

How to test it:

• Map all endpoints accessible to an admin user
• Attempt to access each admin endpoint with a regular user token
• Test HTTP method tampering (if GET works, try POST, PUT, DELETE)
• Look for hidden admin APIs by examining client-side JavaScript, API documentation, or predictable URL patterns (/api/admin/, /api/internal/)

API6: Unrestricted Access to Sensitive Business Flows

Some business flows should not be automated at scale — purchasing limited items, creating accounts, submitting reviews. If the API does not distinguish between human and automated usage, attackers can abuse these flows.

How to test it:

• Script the business flow and run it at scale
• Check for CAPTCHA or proof-of-work requirements
• Look for device fingerprinting or behavioral analysis
• Test if rate limits apply to the business flow, not just individual endpoints

API7: Server-Side Request Forgery (SSRF)

APIs that fetch external resources based on user input are SSRF targets.

How to test it:

• Submit internal IP addresses (http://169.254.169.254/ for cloud metadata, http://localhost:port/)
• Use DNS rebinding techniques
• Submit URLs with non-HTTP schemes (file:///etc/passwd, gopher://)
• Check if the API follows redirects from external URLs to internal addresses

API8: Security Misconfiguration

This covers a broad range of issues from missing security headers to overly permissive CORS to exposed debug endpoints.

How to test it:

• Check CORS configuration with requests from unauthorized origins
• Look for exposed documentation endpoints (/swagger, /graphql/playground)
• Check HTTP methods (OPTIONS request to discover allowed methods)
• Look for verbose error messages that disclose stack traces or internal details
• Check TLS configuration and cipher suites

API9: Improper Inventory Management

You cannot secure APIs you do not know about. Shadow APIs, deprecated versions, and test endpoints in production are common findings.

How to test it:

• Compare API documentation with actual deployed endpoints
• Check for version prefixes (/v1/, /v2/) and test if older versions are still active
• Look for common API paths (/api/, /rest/, /graphql/, /internal/)
• Check subdomain enumeration for API hosts
• Review client-side code for hardcoded API endpoints

API10: Unsafe Consumption of APIs

When your API consumes data from third-party APIs, it should treat that data as untrusted.

How to test it:

• Identify third-party API integrations
• Test if data from these APIs is validated and sanitized before use
• Check if third-party API failures are handled gracefully (no cascading failures)
• Verify that third-party API calls use TLS and authenticate properly

Building a Testing Methodology

Randomly testing endpoints is inefficient. A structured approach:

1. Discovery. Map all API endpoints from documentation, traffic analysis, and code review.
2. Classification. Categorize endpoints by authentication requirements, data sensitivity, and function.
3. Prioritization. Focus on endpoints that handle sensitive data, perform authorization decisions, or interact with external systems.
4. Testing. Work through the OWASP API Top 10 systematically for priority endpoints.
5. Automation. Encode repeatable tests into your CI/CD pipeline for regression coverage.

Tooling for API Security Testing

No single tool covers all API security risks. A practical toolkit:

• Burp Suite or OWASP ZAP for proxy-based testing and active scanning
• Postman or Insomnia for manual request crafting and collections
• Autorize (Burp extension) for automated authorization testing
• GraphQL Voyager for schema visualization
• Custom scripts for business logic testing that tools cannot automate

How Safeguard.sh Helps

Safeguard.sh addresses API9 (Improper Inventory Management) directly by maintaining a comprehensive inventory of your software components and their APIs through SBOM tracking. When you know exactly what components are deployed and what versions are running, shadow APIs and forgotten endpoints become visible. Safeguard.sh's continuous monitoring surfaces known vulnerabilities in the libraries and frameworks powering your APIs, ensuring that even well-tested APIs are not undermined by vulnerable dependencies underneath.