API Security Testing: Find BOLA, Mass Assignment, and Data Exposure Before Attackers Do
Written by the Rafter Team
API security testing is the practice of probing your REST and GraphQL endpoints for vulnerabilities that traditional web scanners miss entirely. APIs expose raw business logic — no UI layer to obscure the attack surface. Broken Object Level Authorization (BOLA), mass assignment, and excessive data exposure are the three most exploited API flaws, and none of them show up in a standard SAST scan.
Your web application scanner tests what the browser sees. Your API has dozens of endpoints the browser never touches — admin routes, internal microservice calls, batch operations. Every one of them is a potential entry point.
BOLA is the #1 API vulnerability. If your API returns user data based on an object ID in the request and you only check authentication (not authorization), any authenticated user can access any other user's data by changing the ID. This is trivially exploitable and accounts for the majority of API breaches.
Scan your APIs for BOLA and authorization flaws with Rafter — connect your OpenAPI spec and get results in minutes.
The API-Specific Vulnerability Classes
Standard vulnerability categories don't capture what goes wrong in APIs. The OWASP API Security Top 10 defines the threats that matter.
BOLA (Broken Object Level Authorization) happens when your API trusts the client to request only its own resources. An attacker changes /api/users/123/orders to /api/users/124/orders and gets someone else's data. The fix is server-side authorization checks on every object access — not just authentication at the gateway.
Mass assignment occurs when your API binds request parameters directly to internal data models. An attacker adds "role": "admin" to a profile update request, and your ORM writes it to the database. You must explicitly whitelist which fields each endpoint accepts.
Excessive data exposure means your API returns full data objects when the client only needs a subset. A /api/users/me endpoint that returns password hashes, internal IDs, or billing details alongside the display name gives attackers free reconnaissance. Serialize only what the consumer needs.
Testing REST and GraphQL APIs
REST APIs are testable with your OpenAPI specification. Import your spec into a DAST tool, and it understands every endpoint, parameter, and expected response format. The scanner generates malicious inputs for each parameter type — SQL injection in string fields, boundary values in integers, authorization bypass attempts on every route.
GraphQL adds complexity. A single endpoint accepts arbitrary queries, so traditional URL-based crawling fails. You need tools that understand the GraphQL schema, test query depth limits, check for introspection exposure in production, and probe for batching attacks that bypass rate limiting.
For both API types, test authorization at the object level. Send requests as User A for User B's resources. Automated tools can do this if you provide multiple authentication tokens and define the resource ownership model.
OpenAPI Specs and Specialized API Scanners
Generic DAST tools bolt on API support as a feature. Specialized API security scanners build around it. The difference matters when your API has hundreds of endpoints with complex authentication flows.
Feed your OpenAPI or Swagger spec directly into your scanner. It eliminates the crawling problem — the tool knows every route, every parameter type, and every expected response code. Without a spec, the scanner guesses, and it will miss endpoints that aren't linked from discoverable routes.
Run API security tests in CI against your staging environment. Test after every deployment, not quarterly. API surfaces change faster than web UIs, and a single new endpoint with missing authorization checks is all an attacker needs.
Add Rafter to your CI pipeline — test your API endpoints for authorization flaws on every pull request.