---
title: 'AuthREST: Automated API Security Testing'
url: https://www.emergentmind.com/topics/authrest
type: topic
---

# AuthREST: Automated API Security Testing

AuthREST is an open-source automated black-box security testing tool for web APIs that targets broken authentication, specifically credential stuffing, password brute forcing, and unchecked token authenticity. It assumes access only to an API’s HTTP interface and its OpenAPI specification, and it generates and executes security test cases as HTTP request sequences rather than isolated requests. The system is positioned as a specification-guided, implementation-agnostic extension of black-box API testing toward a vulnerability class that the authors characterize as both prevalent and insufficiently supported by prior automated API testing tools [2509.10320].

## 1. Broken authentication in the web API setting

AuthREST is motivated by the operational centrality of APIs and the corresponding growth of API attack surfaces. In the formulation associated with the tool, broken authentication is one of the most prevalent and operationally important API security risks because APIs mediate critical business functions and large volumes of Internet traffic, while authentication failures can enable systematic guessing of credentials, large-scale reuse of leaked credentials, or bypass of token-based access controls [2509.10320].

The work emphasizes that API authentication differs materially from browser-centric web authentication testing. API login and token use are directly scriptable, highly automatable by attackers, and exposed through machine-readable interfaces, so flaws can often be exploited efficiently and repeatedly. This framing explains the tool’s focus on three attack classes: credential stuffing, password brute forcing, and unchecked token authenticity. Within the authors’ survey of prior API testing literature, these classes are treated as common in practice but not previously addressed by a fully automated approach for broken authentication in web APIs [2509.10320].

AuthREST is referred to in the paper’s body as `\securest`. Its scope is web APIs, such as REST APIs, described by OpenAPI. The approach is black-box and HTTP-based, and is therefore claimed to be independent of server language and framework. A practical implication is that AuthREST targets externally observable security behavior rather than source-level causes.

## 2. Architecture, inputs, and execution model

AuthREST is implemented on top of the RestTestGen framework. Its required machine-readable input is an OpenAPI specification, and its security model assumes no access to source code or implementation internals. The overall pipeline is: parse the OpenAPI description, extract or infer the information needed to build tests, automatically generate black-box security test cases as sequences of HTTP requests, execute those sequences against the target API, record the HTTP interaction history, and apply vulnerability-specific oracles to produce a security report [2509.10320].

This architecture combines several elements. First, it uses specification mining to identify authentication-relevant operations and parameters. Second, it reuses RestTestGen’s existing capability for generating valid request data and dependency-aware request sequences. Third, it adds authentication-specific test strategies and security oracles. For unchecked token authenticity in particular, the tool relies on RestTestGen’s nominal strategy, which orders operations according to producer-consumer data dependencies and supplies inputs from the specification, from prior successful interactions, and from random generation. This does not formalize authentication state as an abstract state machine; instead, it records concrete successful authenticated sequences under a correct token and uses those traces as the baseline authenticated behavior [2509.10320].

The emphasis on request sequences is significant. AuthREST’s “comprehensive test cases” are HTTP interaction sequences rather than individual requests, which is especially relevant for stateful APIs whose later requests depend on values produced by earlier ones. This makes the tool closer to specification-guided stateful testing than to single-request fuzzing.

AuthREST occupies a distinct position relative to adjacent REST API testing systems. AutoRestTest, for example, is a black-box REST API testing tool based on online single-agent Q-learning, but it is not an authentication-focused framework and explicitly excluded several benchmark services because authentication issues prevented meaningful responses [2501.08600]. RESTifAI, by contrast, is an LLM-based workflow for generating reusable happy-path and negative REST API tests, yet it does not present dedicated handling for authentication workflows, authorization policies, bearer token acquisition or refresh, role-based access control, or protected-versus-public endpoint classification [2512.08706]. AuthREST’s specificity lies in making broken-authentication testing itself the primary objective.

## 3. Detection strategies for authentication abuse and token validation

AuthREST automates three vulnerability classes.

Credential stuffing is modeled as repeated login attempts from the same client using many username/password combinations. The key assumption is that, from the API’s perspective, randomly generated credentials are behaviorally equivalent to real stolen credentials, so actual compromised accounts are not required for the test. The secure behavior expected by the tool is the appearance of some mitigation after a small burst of suspicious attempts, such as rate limiting, temporary blocking, challenge mechanisms, or two-factor authentication. The insecure behavior is continued unrestricted processing of many login attempts with unchanged failure responses [2509.10320].

Password brute forcing reuses essentially the same machinery, but the attack fixes a target user identifier and varies only the password across repeated attempts. The rationale is that APIs may distinguish broad credential stuffing from focused brute force against one account. AuthREST therefore keeps the user identifier constant while mutating only the password value, but retains the same expected mitigations and the same evidence of failure as in credential stuffing [2509.10320].

Unchecked token authenticity targets APIs that use bearer tokens or similar tokens for authentication but fail to verify authenticity properly. The threat model is direct unauthorized use of malformed or tampered tokens to access protected resources or functionality. In a secure API, such requests should be rejected with `401` or `403`; in an insecure API, invalid tokens may still yield `2xx`, enabling unauthorized access or actions [2509.10320].

This third strategy is more stateful than the login-abuse strategies. AuthREST first performs nominal exploration with a correct user-supplied token, records all successful authenticated interactions, and then replays the recorded sequence while mutating the token differently for each request. The mutation operators are protocol-aware: one alters a single character of the valid token while preserving structural delimiters such as dots in JWTs and using only valid token characters; one removes one random character while preserving JWT structural characters; and one adds one random valid character. These mutations are intended to create realistically malformed or tampered tokens without trivially destroying overall token format [2509.10320].

## 4. Heuristic inference and vulnerability oracles

AuthREST’s detection logic is intentionally lightweight and rule-based. For login-abuse testing, it identifies login operations and login-related parameters from the OpenAPI specification using heuristics derived from a manual study of 100 APIs from APIs.guru. A login operation is heuristically classified as a `POST` or `GET` whose path contains “login” or “signin” after stripping nonalphabetic characters. Parameter identification is priority-based: password parameters are searched first by names containing `password`, and if none exist, by names containing `pass`; user identifier parameters are prioritized by substring matches in the order `username`, `email`, `login`, `user`, `phone`, `mail`, and `id`, after removing non-alphanumeric characters. The ordering is explicitly intended to distinguish genuine login identifiers from unrelated resource identifiers, as in the example that `userId` should match `user` before `id` [2509.10320].

Once the login endpoint and key parameters are identified, AuthREST builds repeated-request scenarios. Auto-identified user and password fields are given random values. Additional required parameters are filled using RestTestGen’s input value providers, which may draw from example values in the OpenAPI specification, enum values, values seen in prior successful requests and responses, and random generators. For credential stuffing, the tool sends 100 login requests within 10 seconds, an intentionally aggressive burst designed to trigger standard defensive controls; the authors also cite OWASP guidance that countermeasures should appear after roughly 3–10 rapid requests from the same source [2509.10320].

The oracle for credential stuffing and brute force checks two conditions. First, the API should exhibit rate limiting, operationalized as returning HTTP `429 Too Many Requests`. Second, the error messages should not remain semantically unchanged across the attack sequence. To compare messages robustly, the oracle normalizes them with Porter stemming and uses token overlap rather than literal string equality. Two messages are treated as the same error if they share at least 70% of the tokens. If no `429` appears and repeated failures remain in the same error-message class under that 70% criterion, the tool reports a missing lockout mechanism [2509.10320].

For unchecked token authenticity, the principal false-positive source is that public endpoints may ignore both valid and invalid tokens and still return success. AuthREST compensates by executing a third trace in which the token is omitted entirely. Let `W` be the set of operations successfully executed with incorrect mutated tokens, and let `N` be the set of operations successfully executed with no token at all. The paper defines the final set of vulnerable operations as
$$
V = W - N
$$
so that endpoints public by design are excluded from the report [2509.10320].

A plausible implication is that AuthREST’s oracles are best understood as pragmatic security predicates over observable HTTP behavior rather than formal proofs of exploitability. This is explicit in the work’s design: there is no probabilistic model, no formal semantics of authentication state, and only one explicit formula.

## 5. Empirical validation and reported findings

The empirical validation uses a benchmark of six publicly accessible real-world APIs: Here, ID4I, 6 Dot, BRAINBI, BeezUP, and Tradematic. The benchmark was constructed from APIs.guru. The authors initially sampled 50 APIs manually for suitability and excluded APIs that were unreachable, non-working, lacked authentication, or did not explicitly list a login operation in their OpenAPI specification. This benchmark design directly exposes one practical dependency of the approach: the login-abuse strategies require the login operation to be documented in the specification [2509.10320].

Experiments were repeated 10 times because the tool includes nondeterministic elements such as random value generation. Reported true positives and false positives were averaged over those ten executions. Vulnerability reports were manually validated through inspection of generated HTTP histories and then confirmed by manual exploitation using Postman. The evaluation also states ethical constraints: credential stuffing and brute-force tests used generated credentials and checked only for the presence or absence of mitigation mechanisms, while unchecked-token experiments were monitored closely to avoid harmful side effects [2509.10320].

For credential stuffing and password brute forcing, four of the six tested APIs—Here, ID4I, 6 Dot, and BRAINBI—were found vulnerable, and every reported issue was manually confirmed. In the validation table, these four APIs show `1.0` true positives and `0.0` false positives for both strategies. BeezUP and Tradematic showed no such vulnerabilities. All reported vulnerabilities were described as previously unknown and were disclosed to the API owners. On the observed reports, precision was therefore 100%, with no false positives; false negatives could not be measured because no complete ground truth was available [2509.10320].

The unchecked-token-authenticity evaluation was much narrower. Only Tradematic was suitable because the other APIs were either commercial and required subscriptions or lacked valid credentials needed to exercise token-authenticated behavior. AuthREST reported no vulnerabilities in Tradematic. The authors treat this as evidence that the method is not obviously prone to false positives, but they also state that a single-API case study is insufficient to generalize performance for this strategy [2509.10320].

## 6. Limitations, deployment conditions, and significance

Several limitations follow directly from the design. The approach depends on the availability and quality of an OpenAPI specification; if the specification is incomplete, inaccurate, or omits authentication endpoints, vulnerabilities may be missed. The login-operation and parameter-detection heuristics are naming-based and therefore susceptible to false negatives for unconventional paths or field names. The credential-stuffing and brute-force strategies detect the absence of common mitigations rather than proving end-to-end account compromise. The token-authenticity evaluation is underpowered. The 70% error-message similarity threshold is heuristic. Recall cannot be estimated because there is no complete vulnerability ground truth for the tested APIs [2509.10320].

The paper also notes practical edge cases. For login-abuse testing, some defenses may be real but invisible to the current oracle, such as silent slowdown, tarpitting, out-of-band account alerts, per-IP reputation scoring, or mitigations triggered only after a threshold larger than the test’s assumptions. Conversely, false negatives may arise if the API uses naming conventions outside the heuristic vocabulary, if defenses trigger only under network conditions not reproduced by the tester, or if token verification fails only for malformed-token classes not generated by the current mutation operators [2509.10320].

Deployment is easiest in security QA or continuous testing settings where OpenAPI specifications are maintained and test credentials or tokens can be supplied safely. Because the approach is black-box and attack-like, rate and timing control matter: sending 100 login attempts in 10 seconds to a production service may trigger SOC alerts, violate acceptable-use policies, or interfere with operations. The work therefore implicitly favors staging environments, coordinated maintenance windows, or allowlisted testing. Another practical constraint is that unchecked-token-authenticity testing requires a correct token to establish the authenticated baseline, so that mode is not fully zero-knowledge [2509.10320].

Within the broader API testing literature, AuthREST’s main contribution is not a new general-purpose test-generation engine but a focused automation of broken-authentication checks that had largely remained manual or ad hoc. It leverages prior advances in black-box API testing—especially specification-guided sequence generation and dependency-aware nominal exploration—while adding authentication-specific heuristics, replay-based mutation strategies, and security oracles. Its principal strengths are black-box applicability, automation, and the discovery of previously unknown authentication weaknesses in public APIs. Its principal weaknesses are heuristic dependence, limited formalization, and modest evaluation breadth, especially for token authenticity [2509.10320].

Source: https://www.emergentmind.com/topics/authrest