API security assessment: what automated tools miss and manual testing finds
Key takeaways
Broken Object Level Authorization (BOLA) is the most common high-severity finding in Vulnox API assessments and the one automated scanners are least equipped to detect, because detecting it requires understanding what object a user should be authorized to access.
JWT algorithm confusion vulnerabilities, where a server accepts tokens with the alg header set to none or to a symmetric algorithm when asymmetric signing is expected, survive code review processes because the flaw is in library configuration, not in the code the reviewer is reading.
Internal API endpoints that assume network position as an authentication control are an exploitable misconfiguration, not a missing feature: the assumption is that internal equals trusted, and that assumption fails the moment an attacker has any internal foothold.
Mass assignment vulnerabilities in REST APIs allow attackers to set object properties that the application did not intend to expose, and they are introduced every time a new field is added to a data model without updating the API input allowlist.
API documentation endpoints left accessible in production, including Swagger UI and GraphQL introspection, provide attackers with a complete map of the attack surface that would otherwise require significant reconnaissance effort.
TL;DR
API security scanners find what they can enumerate: known vulnerability signatures, missing headers, basic injection patterns. The findings that produce the largest blast radius in real incidents are logic flaws, authorization gaps, and configuration assumptions that require a tester to understand the API before probing it. BOLA, mass assignment, and JWT misconfiguration are not scanner findings. They are assessment findings. The distinction matters because most organizations believe their automated scans cover the API attack surface.
The API that had authentication and no authorization
A 200-person logistics company had a REST API serving their customer portal. Every endpoint required a valid JWT. The authentication implementation was correct: tokens were signed with RS256, expiry was enforced, and the library was configured to reject the none algorithm. Their security team had reviewed the authentication implementation during a code audit six months prior and marked it complete. The API had passed an automated security scan with no critical findings.
Manual assessment found that the order retrieval endpoint accepted any valid JWT regardless of which customer account the token belonged to. A token issued to customer A, passed with a request for customer B orders, returned customer B order history including addresses, contents, and delivery schedules. The object identifier in the request path was not validated against the authenticated user identity. The authentication was working. The authorization was absent. The automated scanner had confirmed that the endpoint required authentication. It had no mechanism for determining whether the authenticated user should have access to the object they were requesting.
Why BOLA survives automated scanning
Broken Object Level Authorization requires the testing tool to understand the relationship between an authenticated identity and a specific object before it can determine whether access to that object is authorized. An automated scanner authenticates as a test user and probes endpoints. It can detect whether authentication is required. It cannot determine whether the authenticated test user should be permitted to access the specific resource identifier it is requesting, because that determination requires knowledge of the application data model and the intended access control policy.
Example
The logistics API used sequential integer order IDs in the path: GET /orders/12345. An automated scanner authenticating as a test user with access to order 12345 would successfully retrieve that order and record the endpoint as accessible. It would not attempt to access order 12346 with the same token and verify whether that access should be denied, because the scanner has no basis for knowing that 12346 belongs to a different customer. A manual tester who reads the API documentation, authenticates as two different test customers, and attempts cross-customer object access with each identity detects the vulnerability in under ten minutes. The scanner needs the context. The manual tester creates it.
JWT algorithm confusion is a distinct class of implementation flaw that survives code review for a specific reason: the flaw is in the library initialization configuration, not in the JWT handling code the reviewer is reading. A developer who reviews the JWT validation middleware sees token expiry checks, signature verification calls, and claim extraction. The library call that enables or disables the none algorithm and that specifies which algorithms are acceptable is typically a single configuration line in the library instantiation, often in a separate configuration file, and often using a default that permits more algorithms than the application intends to accept. The code review confirms that JWT validation runs. It does not confirm what the validator accepts.
What API assessments show that scans do not
Assessment base: Vulnox vulnerability assessment data across SMB and mid-market clients, 2023-2024
BOLA present in majority of assessed APIs with object-level data retrieval
In Vulnox API assessments where the API served user-specific or account-specific data, broken object level authorization appeared as a finding in the majority of engagements. The pattern was consistent: authentication was implemented correctly, often reviewed and documented as a completed security control, while authorization at the object level was either absent or inconsistently applied. The most common root cause was that authentication and authorization were treated as a single implementation task. Once authentication was implemented and reviewed, authorization was considered addressed.
Authentication confirms identity. Authorization confirms entitlement. They are different controls implemented separately and failing in different ways. An API security assessment that verifies authentication is present has not verified that authorization is correctly applied. For any API endpoint that returns user-specific or account-specific data, authorization needs to be tested by attempting cross-identity object access with valid credentials.
Internal API endpoints with no authentication reachable from the application network segment
A SaaS platform serving mid-market clients had an internal reporting API that generated account summary data for the customer success team. The endpoint required no authentication because it was accessible only from the internal network and the assumption was that internal users were trusted. Vulnerability assessment found the endpoint reachable from the application server segment. Any process running on the application servers could query any customer account summary without authentication. The application servers processed customer-supplied data including file uploads. A server-side request forgery vulnerability in the file processing pipeline would have provided a path from attacker-controlled input to unauthenticated access to all customer account data.
Network position is not an authentication control. It is a network access control that reduces the population of clients that can reach the endpoint. It does not authenticate any of those clients. Internal endpoints without authentication rely on the assumption that every process that can reach them is trusted. That assumption fails whenever an attacker has any foothold in the network segment, including through SSRF, compromised internal services, or lateral movement from a phishing compromise.
Mass assignment enabling privilege escalation through undocumented writable fields
A B2B platform used a PATCH endpoint for user profile updates. The endpoint accepted a JSON body and applied any fields present in the request to the user object. The API documentation listed the fields the endpoint was intended to accept: name, email, phone. The underlying user object also contained a role field and an account_tier field that controlled feature access and billing tier. Neither was documented as writable through the PATCH endpoint. Both were writable. An authenticated user sending a PATCH request with role: admin and account_tier: enterprise in the body received a 200 response and the changes were applied.
Mass assignment vulnerabilities are introduced at the data model layer every time a new field is added without updating the API input allowlist. They are invisible to automated scanners because the scanner does not know which fields are intended to be writable. Detection requires a tester who reads the data model, identifies fields with security implications, and tests whether those fields are accepted by endpoints that should not expose them.
Swagger UI accessible in production with full endpoint documentation and example requests
In a consistent pattern across assessed environments, API documentation endpoints including Swagger UI, ReDoc, and in one case a GraphQL playground with introspection enabled were accessible in production without authentication. The development teams had not disabled them after deployment because the documentation was useful for client integrations. In each case, the documentation provided endpoint paths, parameter names, data types, example request bodies, and in some cases example responses including data structure. An attacker with no prior knowledge of the application received a complete attack surface map from the documentation endpoint before sending a single probe request to a functional endpoint.
API documentation in production is a reconnaissance accelerant. It does not introduce vulnerabilities that would not otherwise exist, but it eliminates the discovery effort that would otherwise slow an attacker. For APIs where authorization flaws exist, documentation reduces time-to-exploit by providing the endpoint structure and parameter names needed to construct targeted requests.
The API gateway that made the authorization problem harder to find
Common belief
API gateways centralize authentication enforcement and reduce API vulnerability risk. An organization that routes all API traffic through a gateway with authentication policies applied has addressed the primary API security concern.
What we found
In assessments of API architectures with gateway authentication, the BOLA finding rate was not lower than in architectures without gateways. The gateway had addressed authentication. The authorization gap at the object level was unchanged. More specifically: in several environments, the presence of the gateway had increased organizational confidence in API security to the point where object-level authorization had not been included in the API security review scope, because authentication was considered handled. The gateway solved one problem and created a blind spot for another.
API gateways enforce authentication at the perimeter. They confirm that requests carry valid credentials before passing them to the backend service. What they do not do is enforce object-level authorization within the backend service. A gateway that validates a JWT and passes the authenticated request to the order retrieval service has confirmed the user identity. The order retrieval service still needs to verify that the authenticated user is entitled to the specific order being requested. Gateway authentication and service-level authorization are different controls at different layers.
The API surfaces most assessments do not cover
Webhook endpoints receiving externally-originated payloads
Webhooks are API endpoints that receive data from external systems rather than sending it. They are typically not included in standard API security assessment scope because they are not user-facing. They receive payloads from third-party platforms including payment processors, communication services, and integration platforms. If the webhook endpoint does not verify the signature or shared secret that should accompany the payload, an attacker can send arbitrary payloads to the endpoint and trigger whatever business logic the webhook executes.
GraphQL query depth and complexity limits
GraphQL APIs that do not enforce query depth or complexity limits are vulnerable to resource exhaustion through deeply nested or complex queries. A single malformed GraphQL query can trigger database operations that would take seconds or minutes to resolve, allowing an attacker to deny service or extract large volumes of data through a small number of requests. This is not a standard injection vulnerability and will not appear in scanners configured for REST API testing.
API versioning leaving deprecated endpoints active
Organizations that version their APIs frequently leave prior versions active during transition periods. Deprecated API versions may lack security controls added to current versions, including authentication requirements, rate limiting, and input validation. An attacker who identifies the version pattern, often visible in the URL structure or in response headers, and tests prior versions may find endpoints that have been hardened in the current version but remain exposed in deprecated ones.
Mobile application API endpoints not documented in the web API specification
Mobile applications frequently communicate with backend API endpoints that are not documented in the same API specification as the web application. Mobile-specific endpoints are discovered through application binary analysis or traffic interception rather than through documentation review. These endpoints are often not included in security assessment scope because they are not listed in the API specification that defines the assessment target.
How a manual API assessment differs from an automated scan
- Step 1
Map the intended authorization model before testing
Output:An authorization matrix mapping user roles to object access entitlements, used as the baseline for cross-identity access testing.
Purpose:BOLA cannot be tested without understanding which user should be authorized to access which objects. This requires reading documentation, creating test accounts in multiple roles, and building a matrix of which identity should and should not be able to access which object types before sending a single probe request.
- Step 2
Test cross-identity object access with valid credentials from each role
Output:A list of endpoints where cross-identity object access succeeds, indicating absent or inconsistently applied object-level authorization.
Purpose:For each object type returned by the API, authenticate as user A and request objects belonging to user B. Repeat across all role combinations in the authorization matrix. An automated scanner cannot perform this test because it does not know which objects belong to which identity.
- Step 3
Enumerate all fields accepted by write endpoints against the data model
Output:A list of fields with security implications that are accepted by write endpoints outside their intended scope.
Purpose:Mass assignment requires comparing what the endpoint accepts against what the application intends it to accept. This means reading the data model, identifying fields with security implications (role, status, tier, verified, admin), and testing whether those fields are processed by endpoints not intended to expose them.
- Step 4
Test JWT configuration by attempting algorithm substitution
Output:Confirmation of which algorithm values the server accepts and rejects, with evidence of rejection for each non-permitted algorithm.
Purpose:Verify that the server rejects tokens with the alg header set to none, HS256 when RS256 is expected, and any algorithm not in the application allowlist. This requires constructing modified tokens, not just observing server responses to normal tokens.
- Step 5
Identify all endpoints not in the primary API specification
Output:A complete endpoint inventory including undocumented surfaces, with authentication and authorization state for each.
Purpose:Webhook receivers, mobile API endpoints, internal endpoints reachable from the application network segment, and deprecated versioned endpoints are all out-of-specification surfaces. Discovery requires DNS enumeration, traffic analysis, and binary analysis of any available client applications, not just review of the documented API.
Where API security assessment is heading
BOLA will be named as the specific finding class in a majority of significant API breach disclosures within two years, as post-incident analysis becomes more technically specific and organizations are required to disclose the mechanism of unauthorized data access.
Regulatory breach disclosure requirements are becoming more technically specific. GDPR enforcement actions increasingly name the specific technical failure. BOLA produces exactly the breach pattern that appears in current disclosures: authenticated access to data belonging to other users, often detected through anomalous access patterns rather than through security monitoring. As the forensic language for describing these incidents becomes standardized, BOLA will be named where it currently appears as unauthorized access or access control failure.
Confidence: highBOLA appearing as a named finding class in more than half of significant API breach post-mortems published between 2025 and 2027.LLM-generated API code will produce a new category of mass assignment vulnerability within two years, because code generation models trained on web tutorials produce endpoints that accept full request bodies without field filtering, which is the correct pattern for tutorials and an exploitable misconfiguration in production.
Code generation tools produce API endpoint handlers that match training data patterns. Tutorial and example code rarely implements input allowlisting because it obscures the core concept being demonstrated. Models trained on this data generate production code that accepts arbitrary fields. The developer reviewing AI-generated code reviews it for functional correctness, not for the presence of an input allowlist that was never in the example the model learned from.
Confidence: highA published security analysis of LLM-generated API code documenting mass assignment as a systematic output pattern by end of 2026.
Why API security scans have become a liability disguised as a control
The problem with automated API security scanning is not that it finds nothing. It is that it finds enough to produce a report that organizational stakeholders treat as coverage. A scan that identifies missing rate limiting, absent security headers, and basic injection points produces a finding list that looks like a security assessment. It is not. It is a list of things the scanner was built to find, which is a subset of the things an attacker will look for. The organization remediates the scan findings, marks API security as assessed, and has a documented gap between what was tested and what matters. BOLA, mass assignment, and JWT misconfiguration are not exotic vulnerabilities. They are in the OWASP API Top 10. They are absent from most automated scan reports because they require context that automated tools do not have. An organization that runs API security scans and does not supplement them with manual testing has documented evidence that they looked and a gap in what they actually found.
Counterargument
The counterargument is that automated scanning covers the high-volume, low-effort vulnerabilities that attackers use for opportunistic targeting, and that manual testing is resource-intensive and appropriate only for high-value APIs. That is a reasonable prioritization argument. It is not an argument that automated scanning constitutes an API security assessment. The distinction matters because organizations that conflate the two have a compliance document that does not reflect their actual tested security posture.
One thing to do this week
Pick one API endpoint in your application that returns user-specific or account-specific data. Authenticate as two different test users. With user A credentials, request the object identifier that belongs to user B. If the server returns user B data, you have a BOLA vulnerability on that endpoint. The test takes ten minutes and requires no tooling beyond a browser or curl. If the test fails on the first endpoint, run it on the next five. If it passes on all of them, document the test, the date, and the endpoints covered. You now have evidence that object-level authorization was verified on those endpoints, which is more than most API security scan reports can show.
Further Reading
Vulnerability Assessment
comprehensive vulnerability assessmentDigital Footprint
digital footprint analysisOWASP Web Security Testing Guide
OWASP web security testing guideNational Vulnerability Database NIST
NIST National Vulnerability DatabaseNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guide
Frequently Asked Questions
Why can automated API security scanners not detect broken object level authorization?
Broken Object Level Authorization requires knowing which user should be authorized to access which object before testing whether unauthorized access is possible. Automated scanners authenticate as a test user and probe endpoints, but they have no basis for determining that a specific object identifier belongs to a different user and should therefore be inaccessible. Detecting BOLA requires creating multiple test identities, mapping which objects belong to which identity, and then attempting cross-identity access with valid credentials. This is a context-dependent test that requires understanding the application data model before probing it.
What is JWT algorithm confusion and how does it survive code review?
JWT algorithm confusion occurs when a server accepts tokens with the alg header modified to none or to a weaker algorithm than the application intends to accept. The flaw is in the JWT library initialization configuration, specifically which algorithms the validator is permitted to accept. Code reviewers examining JWT validation middleware see token expiry checks and signature verification calls, but the configuration line that specifies acceptable algorithms is typically in a separate configuration file and uses a library default that may permit more algorithms than intended. The review confirms validation runs. It does not confirm what the validator accepts.
What is mass assignment in API security and how is it introduced?
Mass assignment occurs when an API write endpoint accepts object fields beyond those the application intends to expose, including fields with security implications like role, admin status, or account tier. It is introduced at the data model layer every time a new field is added without updating the API input allowlist for write endpoints. In Vulnox assessments, mass assignment on a B2B platform PATCH endpoint allowed authenticated users to set their own role to admin and account tier to enterprise by including those fields in a standard profile update request. The endpoint was intended to accept name, email, and phone. The data model fields were not filtered.
How does an API gateway enforcement of authentication create a blind spot for authorization testing?
API gateways validate credentials at the perimeter and confirm that requests carry valid authentication before passing them to backend services. They do not enforce object-level authorization within backend services. An organization that implements gateway authentication has addressed one control and still needs to implement object-level authorization in each service. In Vulnox assessments, the BOLA finding rate in architectures with gateway authentication was not lower than in architectures without. Gateway presence increased organizational confidence that API security was addressed, which in several environments meant that object-level authorization had not been included in the security review scope.
What API attack surfaces are most commonly missed in security assessments?
Commonly missed API surfaces in Vulnox assessments include webhook endpoints receiving externally-originated payloads without signature verification, GraphQL endpoints without query depth or complexity limits, deprecated API versions left active during migration that lack controls added to current versions, mobile application API endpoints not listed in the primary API specification, and internal API endpoints reachable from the application network segment that rely on network position instead of authentication. None of these appear in standard automated API scan scope definitions.
How should API security assessment scope be defined to cover authorization gaps?
API security assessment scope for authorization gaps requires: a complete endpoint inventory including undocumented, deprecated, and mobile-specific endpoints; an authorization matrix mapping user roles to object access entitlements before testing begins; test accounts in each role with access to known objects; cross-identity object access testing for every endpoint returning user-specific data; enumeration of all fields accepted by write endpoints against the full data model; and JWT configuration testing that attempts algorithm substitution rather than only verifying that valid tokens are accepted. An assessment scope that defines the target as the documented API specification will miss endpoints and authorization gaps that exist outside that specification.
Related Articles
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
WAF bypass testing: why 84% of deployed WAFs fail under controlled attack conditions
In 63 client environments with deployed WAFs, Vulnox found 84% had at least one exploitable bypass. Most had never been tested under conditions that resembled an actual attack. The WAF was running. It just was not working.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.