API Security Testing: OWASP API Top 10, Burp Suite Workflow, and Automation
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
API security testing requires a different mindset than web application testing. Most critical API vulnerabilities are authorization flaws, not injection flaws: they require understanding the application's data model and testing business logic across multiple authenticated sessions rather than looking for SQL error messages or XSS reflection.
This guide covers the OWASP API Top 10 methodology, Burp Suite and tooling configuration for API-specific testing, automated scanning in CI/CD, and the authorization testing workflow that finds the majority of critical API bugs missed by scanners.
BOLA, BOPLA, and Authorization Testing Methodology
Broken Object Level Authorization (BOLA, also called IDOR) is the most prevalent and impactful API vulnerability class. An API endpoint is vulnerable when it accepts a user-supplied object ID and returns or modifies that object without verifying that the requesting user owns it. Testing methodology: create two test accounts (A and B), perform actions as account A to capture object IDs in requests, then replay those requests authenticated as account B. If account B receives account A's objects, the endpoint is vulnerable. Extend to numeric enumeration: if /api/orders/1001 is accessible, test /api/orders/1000 through /api/orders/999. Broken Object Property Level Authorization (BOPLA) covers excessive data exposure (responses containing fields the application does not display, often including PII) and mass assignment (endpoints accepting fields that should be read-only, such as isAdmin or price).
Burp Suite Configuration for REST and GraphQL API Testing
Configure Burp Suite for API testing by disabling browser-oriented passive scan rules that generate noise against JSON APIs. Use Burp's API specification import feature: import an OpenAPI (Swagger) or Postman collection to auto-generate requests for all documented endpoints. Enable Burp Intruder for fuzz testing: use the Sniper attack type with a wordlist of common parameters (id, userId, accountId, orderId) to discover undocumented parameters. For GraphQL APIs, use InQL (Burp extension) to introspect the schema, enumerate all queries and mutations, and test for authorization bypass on mutations. Enable GraphQL introspection on the target first: send {__schema{queryType{name}}} to verify it is available. Disable JavaScript analysis for pure API testing to reduce scan time.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Broken Authentication and Rate Limiting Flaws
API authentication vulnerabilities differ from web application login attacks. Test for: JWT algorithm confusion (change alg to none or switch from RS256 to HS256, signing with the public key as the HMAC secret), JWT secret brute force using hashcat mode 16500 against a captured token, OAuth token leakage in redirect URIs or referrer headers, and API key exposure in JavaScript source files, mobile app bundles, or public GitHub repositories. Rate limiting bypass techniques: rotate through IP addresses via proxy pool, vary the User-Agent header, append random parameters to defeat naive request fingerprinting, and use decimal variations of integer IDs to bypass exact-match rate limit counters. Test password reset endpoints for user enumeration by comparing response time or error message between valid and invalid email addresses.
Automated API Security Testing With ZAP and Nuclei
Automate API security scanning in CI/CD pipelines using OWASP ZAP in daemon mode and Nuclei with API-specific templates. ZAP API scan: zap-api-scan.py -t openapi.yaml -f openapi -r report.html runs a scan against an OpenAPI specification. For Nuclei, use the api-security template pack: nuclei -u https://api.example.com -t api/ -severity critical,high. The Nuclei API templates cover exposed GraphQL introspection, unauthenticated API endpoints, JWT none algorithm, and known API framework CVEs. Add a custom Nuclei template for your application's BOLA pattern by templating a request with a known valid ID and checking whether a different authenticated session receives a 200 response. Run both tools in pre-production before every release and block merges on critical findings.
The bottom line
Most critical API vulnerabilities are authorization failures that automated scanners miss because they do not understand the application's data model. Build BOLA and BOPLA test cases specific to your API into your CI/CD pipeline using real test accounts. Run them on every deploy. Authorization logic changes break more often than authentication logic, and no scanner catches that automatically. For tool selection between the two leading open-source scanners, see the Burp Suite vs OWASP ZAP comparison. For file upload attack paths that often chain with API authorization flaws, see the file upload vulnerability testing guide.
Frequently asked questions
What is BOLA and why is it the top API vulnerability?
Broken Object Level Authorization (BOLA), also called IDOR (Insecure Direct Object Reference), occurs when an API endpoint accepts a user-supplied identifier (order ID, account ID, document ID) and returns or modifies that object without verifying that the requesting user has authorization to access it. BOLA is the top OWASP API vulnerability because it is pervasive in API design, easy to exploit without special tools, and often exposes highly sensitive data. It cannot be found by looking for injection patterns or missing authentication headers; it requires testing the business logic of access control across two authenticated test accounts.
How do I test for mass assignment vulnerabilities in APIs?
Mass assignment occurs when an API endpoint binds all user-supplied JSON properties to an object model without filtering which properties are allowed. An attacker can add unexpected fields to a POST or PUT body (isAdmin: true, price: 0.01, role: admin) and if the server processes them, the field is set in the database. Testing methodology: send a POST request to an endpoint that creates or updates a resource, add extra fields beyond what the documentation shows, and inspect the response and subsequent GET request to see if the server accepted the extra properties. Common mass assignment targets: user registration endpoints (add role or isVerified), profile update endpoints (add subscriptionLevel), and checkout endpoints (add discountPercentage or finalPrice).
How do I find undocumented API endpoints?
Undocumented endpoints are often the most vulnerable because they bypass security review. Discovery techniques: crawl JavaScript bundles from the web application and extract fetch() calls and URL patterns using LinkFinder or xnLinkFinder. For mobile apps, decompile the APK with jadx and search for string constants matching URL patterns. Use Kiterunner (Assetnote) to brute-force endpoints with an API-specific wordlist: kr scan https://api.example.com -w routes-large.kite. Check robots.txt, sitemap.xml, and .well-known/security.txt for references. Test v1 endpoints if you find v2 endpoints: legacy versions often lack the security controls added to current versions.
What is the difference between REST and GraphQL API security testing?
REST API testing focuses on endpoint enumeration, HTTP method testing (GET vs POST vs PUT vs DELETE authorization differences), and parameter-level authorization checks. GraphQL testing has unique considerations: introspection reveals the entire schema if enabled (send {__schema{types{name}}} to check), batching attacks allow sending hundreds of queries in a single request to bypass rate limiting, field-level authorization is often missing (the root query is protected but individual fields are not), and mutations may have weaker authorization than equivalent REST endpoints. Use InQL Burp extension or GraphQL Voyager to map the schema and identify sensitive types before testing authorization on individual queries and mutations.
How do I secure JWT tokens in an API?
Secure JWT implementation requires: enforce alg validation on the server side and never accept none as a valid algorithm. Set short expiry times (15 to 60 minutes for access tokens) and use refresh tokens stored in httpOnly cookies for web applications. Validate all claims: iss (issuer), aud (audience), exp (expiry), and iat (issued at). Do not store sensitive data in the payload because base64 is not encryption. Use asymmetric signing (RS256, ES256) for tokens consumed by multiple services so the signing key is not shared with validators. Implement token revocation via a short-lived token pattern or a revocation list for logout functionality.
How do I integrate API security testing into CI/CD?
Add three gates to your API CI/CD pipeline: static analysis, pre-deploy dynamic scanning, and post-deploy smoke testing. Static analysis: run Spectral or Vacuum against your OpenAPI spec to enforce security rules (all endpoints must have authentication defined). Pre-deploy: run OWASP ZAP API scan against a staging environment using the OpenAPI spec as input, blocking the pipeline on critical or high findings. Post-deploy: run a Nuclei template scan against the production URL with a limited, safe template set. Add a custom authorization test script that creates two test users, performs BOLA test cases for your critical endpoints, and fails if cross-user data access is possible.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.