Key points
- The review analyzed 69 peer reviewed studies published between 2010 and 2025 on RESTful API security testing, drawn from IEEE, ScienceDirect, Springer, and ACM databases.
- Vulnerabilities are split into two families, ones that live in application logic such as broken authorization, and ones that live in configuration and deployment such as exposed debug endpoints.
- Traditional API gateways and web application firewalls miss business logic abuse and multistep attack sequences because they inspect one request at a time.
- AI and machine learning testing methods, including reinforcement learning agents and large language models, are gaining ground fast but still chase structural coverage more than security specific outcomes.
- The authors name four open research gaps, and all four center on one theme, testing tools do not understand authenticated, stateful, multistep behavior the way a real attacker does.
The core problem, why the usual defenses were not built for this
Most organizations protect their APIs the same way they protect a website, with a gateway in front and a firewall behind it. That approach made sense when the biggest risk was a malformed request or a stray script tag. It does not hold up against how REST APIs actually get abused today. Gateways are built for routing, basic authorization, and rate limiting. They were never designed for deep inspection, and they mostly watch traffic moving in one direction, missing lateral movement between internal services once an attacker gets a foothold.
Web application firewalls fare a little better because next generation versions can read an OpenAPI document and validate incoming fields against it. But that only works if the specification is complete and current, which in practice it rarely is. Firewalls also inspect requests one at a time. An attacker who sends five perfectly legal looking requests in a row, each one nudging a workflow a step further than it should go, will sail right through. This is exactly how business logic abuse works. Nothing in any single request looks wrong. The violation only exists across the sequence.
There is also a deeper architectural mismatch. Web applications constrain what a user can do through a browser interface and a controlled set of pages. REST APIs hand a client direct, flexible access to backend data and logic over a stateless protocol, usually secured with OAuth or a bearer token instead of a browser session. That statelessness is a feature for developers and a gift for attackers, because it removes the natural friction that used to slow down automated abuse. A script can hammer an endpoint with token variations or manipulated identifiers all day without triggering anything a session based defense would recognize as suspicious.
Where REST APIs actually break, a map of the vulnerability landscape
The review organizes vulnerabilities into two broad groups based on where the flaw actually lives. This distinction matters because it tells you who owns the fix, the development team or the operations team, and it tells a testing tool where to even start looking.
Application level weaknesses
These come from how the API itself was designed and coded. The review groups them into four buckets.
Authentication weaknesses cover weak credential validation, poorly handled tokens, and session mismanagement. A striking example the authors cite is CVE-2025-47646, a flaw in a WordPress login plugin with a CVSS score of 9.8, where an unauthenticated attacker could exploit an unprotected registration endpoint and, if the site was misconfigured with a default administrator role, walk away with full control of the system.
Authorization and access control weaknesses are the biggest and arguably the most damaging category. This is where broken object level authorization lives, the flaw where an API trusts a user supplied identifier in a URL without checking whether the requester is actually allowed to touch that resource. The authors point to CVE-2023-38055, a Palo Alto Networks service that let low privilege users reach or modify other users’ resources, scoring a 9.6 on the CVSS scale. Sitting next to it are broken function level authorization, where users invoke operations reserved for higher privileges such as promoting themselves to administrator, illustrated by CVE-2024-5685 in Snipe IT, and broken object property level authorization, where an endpoint hands back more fields than it should, as seen in CVE-2022-34775 affecting a restaurant reservation platform.
Input validation and injection weaknesses are the more familiar territory, SQL injection, cross site scripting, unsafe deserialization, and server side request forgery, where an API is tricked into making requests to internal systems on the attacker’s behalf. Mass assignment sits here too, the bug where an API blindly maps every field in a request body onto a backend object, letting an attacker slip in a role parameter nobody meant to expose, as happened in CVE-2024-40531.
Business logic and workflow flaws are the hardest of the four to catch with any automated scanner, because nothing about them is syntactically wrong. The review cites a case in Shopkit where users could add products to a cart using a negative quantity and effectively increase their account balance through a checkout flow that was never designed to handle negative numbers.
Configuration and deployment level weaknesses
The second family has nothing to do with how the code was written and everything to do with how the system was set up and maintained. Resource and rate control weaknesses show up when nothing stops a flood of requests, as in CVE-2022-22161, where an unauthenticated attacker could push a Juniper router’s management interface to full CPU load simply by flooding it with traffic. Security misconfigurations cover permissive CORS policies, verbose error messages, and exposed debug interfaces. According to the Salt Security State of API Security Report for 2025, cited in the review, 54 percent of real world API attacks exploited a misconfiguration, making it the single most common cause of a breach in that dataset. Insecure integration and dependency weaknesses cover what happens when an API blindly trusts a third party service, the same category that made the Log4j vulnerability catastrophic across cloud platforms everywhere. And API asset and lifecycle management weaknesses cover the quiet killers, zombie APIs that were supposed to be retired and shadow APIs nobody documented, the exact combination that let an unlisted endpoint expose data belonging to roughly 37 million T Mobile customers for more than six weeks before anyone noticed.
Why this taxonomy matters for testing
A tool that only fuzzes input fields will catch injection flaws all day and never notice a broken object level authorization bug, because the malicious request is perfectly well formed. Matching your testing strategy to the right half of this taxonomy is the difference between a clean scan report and a false sense of security.
How attackers chain these weaknesses into an actual breach
The review’s second taxonomy looks at attack technique rather than root cause, and the throughline across every category is that real attacks rarely stop at one exploited flaw. Authorization exploitation covers vertical privilege escalation, where an attacker reaches an administrator only endpoint through a guessed or brute forced URL, and horizontal privilege escalation, where swapping one user identifier for another exposes someone else’s data. Both are made worse when access control decisions rely on things an attacker can trivially fake, such as a Referer header or a client stored role flag.
Authentication attacks focus on credential stuffing, brute forcing, and increasingly on manipulating JSON Web Tokens directly, accepting an unsigned token through the notorious none algorithm trick, brute forcing a weak signing secret, or confusing a system into treating an asymmetric key scheme as symmetric. Injection and input manipulation attacks extend into server side request forgery against internal microservices and cloud metadata endpoints, plus insecure deserialization that can chain across several services because serialized objects tend to travel between them.
Resource exhaustion attacks are not always about brute force floods. The review highlights low and slow strategies, where an attacker gradually ramps up request frequency specifically to stay under the threshold that would otherwise trigger a rate limiting alert. And misconfiguration and infrastructure exploitation attacks lean on exactly the deployment level weaknesses described above, enumerating old API versions, abusing enabled HTTP methods such as TRACE for cross site tracing, or riding a permissive CORS policy straight through the browser’s same origin protections.
How the review was actually built
The methodology itself is worth a moment, because it explains why the conclusions carry weight. The team followed Kitchenham’s guidelines for systematic literature reviews in software engineering, searching IEEE, ScienceDirect, Springer, and ACM with search strings combining REST API terms against security testing, vulnerability, and attack detection keywords. That pulled in 224 records from the four databases plus 33 more from Google Scholar and citation snowballing, for 257 total. After removing 147 duplicates and excluding 41 more on title and abstract review, 69 papers survived a full text eligibility check with zero further exclusions at that stage. Every one of those 69 was coded for its knowledge source, its targeted vulnerability class, its evaluation method, and its reported limitations, then synthesized qualitatively rather than statistically, since the datasets and metrics across studies were too different for a fair quantitative pooling.
The testing landscape, three ways researchers try to find these flaws
The review organizes existing testing approaches around how much a tester actually knows about the system before starting. That single design choice shapes everything about what a tool can and cannot find.
Knowledge based approaches lean on structured information such as an OpenAPI specification or the source code itself. Model based tools such as RESTler, RestTestGen, Morest, and KAT build dependency graphs from the specification to figure out which operations feed into which, then generate request sequences that respect those dependencies. Specification based tools such as Schemathesis and QuickRest validate schema conformance and behavioral consistency. Code based tools such as EvoMaster instrument the actual source code and use search based algorithms guided by real coverage feedback, which is powerful but only works when you have implementation access in the first place.
Behavior based approaches skip static documents entirely and learn from what the API actually does at runtime. This is where the AI driven wave lives. Reinforcement learning tools such as ARAT-RL, DeepREST, and AutoRestTest treat the API as an environment to explore, learning through trial and reward which request sequences reveal new behavior. Large language model tools such as RESTGPT and LlamaRestTest read the natural language descriptions inside an OpenAPI document and infer constraints a purely structural parser would miss entirely, since much of the real business logic in these specifications is buried in plain English description fields rather than formal schema rules.
Vulnerability specific approaches take a narrower, more surgical path, mapping API operations directly onto known weakness categories from CWE and the OWASP API Security Top 10, then generating targeted attacks for each. Tools such as VoAPI2 chase server side request forgery, path traversal, and injection directly, while other frameworks specialize in a single flaw class such as mass assignment or excessive data exposure.
| Approach family | What it needs | What it catches well | Where it struggles |
|---|---|---|---|
| Model and specification based | An OpenAPI document, ideally a complete one | Structural coverage, schema violations, dependency aware sequences | Undocumented behavior, anything the specification never described |
| Code based | Source code access | Deep coverage guided by real execution paths | Language dependence, no visibility once deployed as a black box |
| AI and reinforcement learning based | Live access to the running API | Adaptive exploration, undocumented endpoints, hidden dependencies | Long training time, still optimizes for coverage more than security outcomes |
| Vulnerability specific | A curated list of known weakness patterns | Known flaw classes such as mass assignment or SSRF | Anything novel or context dependent that was not in the pattern library |
The honest read on AI driven testing
Reinforcement learning and large language model tools are genuinely better at exploring an API without a human writing every test case by hand. But the review is candid that most of them still optimize for structural coverage, meaning did we touch every endpoint, rather than for an explicitly security focused objective such as did we find an authorization bypass. Coverage and vulnerability discovery are related but not the same goal, and conflating them is one of the field’s quieter mistakes.
Catching what slips through while the API is live
Testing before release only gets you so far, which is why the review also covers runtime attack detection, the systems watching production traffic for signs of active abuse. Signature based detection, the approach behind most web application firewalls, matches incoming requests against a database of known attack patterns. It is precise and fast but blind to anything novel, and attackers can dodge it with simple payload encoding tricks.
Anomaly based detection tries to learn what normal traffic looks like and flag deviations. Machine learning versions of this range from supervised classifiers trained on labeled attack traffic, such as an SVM based approach that reached a meaningful reduction in false positives, to unsupervised autoencoders that flag high reconstruction error as suspicious without ever seeing a labeled attack example. A more recent wrinkle is few shot learning, aimed at the fact that API traffic datasets are far scarcer than the network traffic datasets intrusion detection research usually relies on. One approach in the review uses a generative adversarial framework built on RoBERTa to synthesize realistic API requests and train a detector from only a handful of labeled examples, trading some computational overhead for the ability to work with limited data.
Rule based detection sits between the two, applying explicit, human written rules for specific attack classes such as cross site request forgery. It produces very few false positives and needs no training data, which makes it a reasonable first layer, but it inherits every blind spot of anything the rule writer did not anticipate.
How researchers actually measure whether any of this works
Evaluation metrics matter more than they get credit for, because a tool that racks up impressive coverage numbers can still miss the vulnerabilities that actually matter. The review groups metrics into three families. Coverage and exploration metrics, such as line coverage, branch coverage, and workflow exploration depth, measure how thoroughly a tool exercises the API. Vulnerability detection metrics count unique confirmed bugs, track failure signals such as unexpected 5XX responses, and increasingly include semantic checks for silent errors that never trigger an obvious status code at all. Performance and practicality metrics cover test generation time, time to first fault, and how efficiently a tool integrates into a real deployment pipeline.
The authors flag a genuine gap here. High structural coverage does not guarantee a tool caught the authorization flaws or logic abuses that actually get organizations breached. A test suite can touch every single endpoint and still walk right past a broken object level authorization bug, because the request that exposes it looks perfectly valid at the schema level.
The toolbox, from Postman to research prototypes
On the practical side, commercial and open source tools such as Postman, Burp Suite, ZAP, and ReadyAPI remain the daily drivers for most teams, handling functional testing, manual security probing, and CI pipeline integration. Fuzzing focused tools such as APIFuzzer and TnT-Fuzzer add randomized input mutation on top of an OpenAPI document. Their shared limitation is that almost all of them test one endpoint at a time and cannot model the stateful, interdependent workflows where the more dangerous vulnerabilities actually hide.
Research tools fill that gap more directly. RESTler and EvoMaster remain the most widely used baselines in academic evaluations, the first for dependency aware stateful fuzzing and the second for white box, source code instrumented test generation. ARAT-RL represents the current edge of adaptive, reinforcement learning driven testing and is increasingly used as a comparison point for newer work. For datasets, intentionally vulnerable testbeds such as OWASP Juice Shop, the Damn Vulnerable REST API, and crAPI give researchers repeatable ground truth environments loaded with known flaws, filling a gap that public API catalogs such as APIs.guru cannot, since those catalogs are built for functional testing and rarely contain a single deliberate vulnerability.
Four problems nobody has fully solved yet
The most useful part of the review, from a practitioner’s chair, is its blunt accounting of what remains broken. Four gaps stand out, and all four trace back to the same root issue, tools do not yet model authenticated, multistep, context dependent behavior the way real attackers exploit it.
The first gap is limited testing of authenticated APIs. Most benchmark tools evaluate themselves against publicly accessible or unauthenticated APIs because it is simply easier to automate. That convenience quietly excludes an entire class of vulnerability, improper token handling, insecure token storage, session fixation, and token replay, all of which only surface once real authentication is in play. OAuth flows, multifactor authentication, and dynamic scope negotiation are rarely captured with enough operational detail in OpenAPI documents for a tool to reproduce them automatically, so black box approaches tend to simplify authentication handling or skip it outright.
The second gap is weak detection of authorization and logic based vulnerabilities. Schema based fuzzing is excellent at finding malformed inputs and terrible at finding a request that is perfectly well formed but violates an access control policy the schema never encoded in the first place. Detecting broken object level authorization requires understanding who is allowed to touch what, a semantic question no amount of syntax checking answers.
The third gap is the lack of multistep, context aware testing. Vulnerabilities such as broken function level authorization or an inconsistent state transition only appear when several calls execute in a specific order under a specific context, something a low privileged user extracting an identifier from one response and using it to reach an administrative feature in a later call. Testing endpoints in isolation, which is still the norm, cannot surface this class of bug at all.
The fourth gap is the absence of reliable security oracles for logic vulnerabilities. A test oracle tells a tool what counts as a failure. Most current tools rely on HTTP 5XX responses as their signal, which works fine for crashes and totally misses a request that executes successfully while still violating a security policy, exposing sensitive data, or letting an unintended state change through. Business rules live in natural language description fields or in backend code that never appears in a specification at all, which makes building a general, reusable oracle for logic violations genuinely hard.
Where the authors point next
The proposed directions are consistent with the diagnosis. Combining runtime execution logs with static specifications to build richer, authentication aware dependency models. Using natural language processing to pull business rules out of description fields and turn them into testable oracles. And applying large language models or reinforcement learning agents to learn expected system behavior through interaction rather than assuming it can all be read off a document in advance.
What this means if you actually own an API
For a team responsible for a production API, the practical takeaway is not that current tools are useless. It is that no single tool covers the whole threat surface, and picking one because it scored well on a coverage benchmark can leave the exact vulnerabilities that matter most completely untested. A specification based fuzzer will catch schema violations and basic injection but will not notice that user A can fetch user B’s invoice by swapping an ID in the URL. A reinforcement learning agent will explore your API far more creatively than a human writing test cases by hand, but if nobody points it at authorization and workflow abuse specifically, it will happily rack up coverage while walking past the one bug that would have made headlines.
The organizations named in the review’s incident table, from a WordPress plugin exposing full account takeover to a router that could be flooded into a coma, were not breached because nobody tested their APIs. They were breached because the testing that happened did not model the specific thing that actually went wrong, an authenticated workflow, a multistep sequence, or a configuration nobody revisited after launch.
Honest limitations of the underlying review
The authors are upfront about the boundaries of their own work. Search string bias is a real risk, since relevant studies using different terminology than the predefined keywords could have been missed. Database coverage bias is possible too, given that some regional or niche venues fall outside the four major databases searched. Publication bias likely tilts the sample toward studies reporting positive results, since papers with negative or inconclusive findings are less likely to get published in the first place. And because the underlying studies use wildly different datasets, metrics, and experimental setups, the authors explicitly chose a qualitative synthesis over a quantitative meta analysis, which means this review offers a structured map of the field rather than a single number ranking one tool against another.
Conclusion
Strip away the acronyms and this review lands on a fairly simple point. REST APIs are attacked the way they are used, through sequences of legitimate looking requests that individually pass every schema check while collectively violating an access control policy nobody wrote down anywhere a machine could read it. That is why gateways and firewalls, built to inspect one request in isolation, keep losing to attacks that were never about a single malformed field.
The shift the field is going through right now, from static specification parsing toward reinforcement learning agents and large language models that interact with a live API the way an actual attacker would, is a real conceptual change and not just a tooling upgrade. It moves the testing question from does this request match the schema toward does this sequence of requests reveal a behavior nobody intended, which is a much closer match to how breaches in the incident table above actually happened.
That shift is not unique to API security either. The same tension between structural coverage and outcome specific goals shows up anywhere automated testing meets a system with hidden state, from fuzzing a smart contract to probing a multistep agent workflow. Anyone building AI driven testing tools for a different domain will recognize the four gaps named here almost immediately, because they are really one gap wearing four costumes, tools that do not yet reason about context the way the humans exploiting them already do.
None of this erases the honest limitations. Authenticated, multistep, logic aware testing remains genuinely hard to automate, and the review does not pretend otherwise. Reinforcement learning agents still need real training time. Large language model based test generation still needs a human to sanity check what it produces. Building a security oracle for a business rule that only exists in a product manager’s head is not a problem any tool fully solves yet.
What the review does offer is a clearer map of exactly where the unsolved problems sit, which is more useful than another benchmark leaderboard. If you are choosing a testing strategy for your own APIs, the question worth asking is not which tool scores highest on coverage. It is whether the tool understands your authentication flow, your multistep workflows, and the access control rules that live in your team’s heads rather than in your OpenAPI document. Most tools today, AI driven or otherwise, still answer no to at least one of those three.
Go deeper
Read the full systematic review for the complete vulnerability taxonomy, tool comparison tables, and dataset list.
Frequently asked questions
What is broken object level authorization and why does it show up so often
It happens when an API trusts an identifier supplied by the user, such as an account number in a URL, without independently checking that the requester is actually allowed to access that specific resource. It shows up constantly because it requires no clever exploit, just changing a number in a request, which makes it both extremely common and extremely easy for an attacker to try.
Can AI testing tools fully replace manual API security testing
Not yet, based on what the review describes. Reinforcement learning and large language model tools are strong at exploring an API more broadly and creatively than a person writing test cases by hand, but most of them still optimize for structural coverage rather than explicitly hunting for authorization bypasses or business logic abuse, so a manual review still catches things automated exploration misses.
Why do web application firewalls miss so many API attacks
They generally inspect one request at a time against known signatures or specification rules. Many of the more damaging API attacks, particularly business logic abuse and multistep authorization bypass, only reveal themselves across a sequence of individually valid looking requests, which a single request inspection model is not built to see.
What is a security oracle in API testing
It is the rule a testing tool uses to decide whether a given response counts as a security failure. Many current tools rely on HTTP error codes as their oracle, which catches crashes but misses a request that returns a normal successful response while still violating an access policy or leaking data it should not.
Which vulnerability category caused the most real world API breaches
According to the Salt Security State of API Security Report for 2025, cited in the review, 54 percent of real world API attacks exploited a security misconfiguration, making it the single most frequently exploited category in that dataset, ahead of authentication and authorization flaws.
Does this review cover GraphQL or gRPC APIs as well
No. The review is scoped specifically to RESTful APIs following REST architectural principles, and studies focused exclusively on other API styles such as SOAP were explicitly excluded from the final set of 69 papers.
Related reading
Source. Abinaya, J, Thilagam, P Santhi, Sivakumar, K, and Pais, Alwyn Roshan. Security testing of RESTful APIs, approaches and research challenges. Computer Science Review, volume 63, 2027, article 101043. Department of Computer Science and Engineering, National Institute of Technology Karnataka, Surathkal. DOI 10.1016/j.cosrev.2026.101043.
This analysis is based on the published paper and an independent evaluation of its claims.