Security

Scanner Reference

Routebase runs 13 scanners across the OWASP API Security Top 10 (2023) — some categories have more than one. You choose which scanners to run in a scan profile; this page documents what each one probes, the severity it raises, and the personas it needs. For the workflow around scanning, findings, and scoring, start with the Security overview.

Scanner catalog

Scanner OWASP category Personas needed Severities raised
api1-bola — Broken Object Level Authorization API1:2023 2+ Critical
api1-bola-enum — BOLA Enumeration (fallback) API1:2023 2+ High
api2-broken-auth — Broken Authentication (passive) API2:2023 None Critical, High
api3-property-auth — Broken Object Property Level Authorization API3:2023 1+ High, Medium
api4-resource-consumption — Unrestricted Resource Consumption API4:2023 None High, Medium
api5-bfla — Broken Function Level Authorization API5:2023 1+ Critical
api6-business-flow — Unrestricted Access to Sensitive Business Flows API6:2023 None Medium
api7-ssrf — Server-Side Request Forgery API7:2023 None Critical, Medium
api8-misconfig — Security Misconfiguration API8:2023 None High, Medium
api8-tls-version — Legacy TLS Version API8:2023 None Medium
api9-inventory — Improper Inventory Management API9:2023 None Medium
fuzz-schema — Schema/Body Fuzzing API4:2023 None High, Medium
fuzz-mutation — Mutation Fuzzing API4:2023 None High, Medium

Scanners that need personas are disabled in the profile editor until you have enough personas in the project. If a persona-requiring scanner ends up with too few personas assigned at run time, it skips its checks and records that it was skipped in the run progress.

The two fuzzing scanners (fuzz-schema, fuzz-mutation) have a second gate: even when selected, they stay silent until the profile's Fuzzing intensity is raised above Off. See Scan profiles for that setting.

Scanner selection list in the scan profile editor with persona badges

API1 — Broken Object Level Authorization (api1-bola)

Personas: 2 or more required.

The BOLA scanner uses a create-then-read approach. For each GET /resource/{id} endpoint it looks for a matching create endpoint (POST /resource on the collection path). If it finds one, it:

  1. Creates a resource as the first assigned persona.
  2. Extracts the id from the response body (it looks for id, uuid, publicId, _id, and similar keys).
  3. Reads that id back as the second persona.

If the second persona gets a 2xx response, the endpoint isn't enforcing ownership and a Critical finding is raised. Endpoints without a matching create endpoint are skipped to keep false positives low, and the scanner probes at most 20 candidate endpoints per run.

Common false positives: genuinely public resources, and resources intentionally shared within a team or organization. Assign personas from different tenants for the most meaningful results, and exclude known-public resources by picking a spec that doesn't include them.

API1 — BOLA Enumeration fallback (api1-bola-enum)

Personas: 2 or more required.

This scanner covers the GET /resource/{id} endpoints that api1-bola skips — the ones without a sibling create POST on the collection path. Instead of create-then-read, it enumerates sequential ids (1 upward) and looks for an endpoint that authenticates the caller but doesn't authorise per object. Because enumeration is weaker evidence than create-then-read, the heuristic is deliberately conservative:

  1. Enumerable check — the first persona reads ids 1..N; if the first few return nothing, the id space isn't sequentially readable (GUIDs and the like) and the endpoint is abandoned.
  2. Anonymous gate — if an unauthenticated request can already read a readable id, the resource is public, not access-controlled, and no finding is raised.
  3. Cross-persona identity — a finding requires that the two personas read the same objects (identical response bodies) for several ids, and that those objects are distinct from one another (so a single constant response for every id doesn't trigger it).

When those conditions hold, it raises a High, medium-confidence finding. It probes at most 10 endpoints per run.

Common false positives: deliberately shared or public catalogues that happen to sit behind auth. Use personas from different tenants so a real cross-tenant read is what the scanner is measuring.

API2 — Broken Authentication (api2-broken-auth)

No personas required. This scanner is passive and runs two probes.

Probe What it does Severity / confidence
JWT alg=none Sends every GET endpoint a bearer token whose header declares alg: none. A 2xx response means the server isn't validating the signature. Critical / Medium
Login rate-limit Finds a login-style POST endpoint (paths matching login, signin, authenticate, auth/token, oauth/token) and fires up to 20 failed login attempts. If it never sees a 429 Too Many Requests, it raises a finding. High / Low

Common false positives: a gateway or WAF that strips malformed JWTs or rate-limits at the edge (above the burst threshold) hides these issues from the scanner — the app-layer weakness may still exist behind it.

API3 — Broken Object Property Level Authorization (api3-property-auth)

Personas: 1 or more required.

For each GET endpoint and each assigned persona, this scanner parses the JSON response and walks it recursively, matching property names against a dictionary of sensitive field names. A match becomes a finding, with the value truncated to 50 characters in the evidence so nothing sensitive is stored in full.

The dictionary is split into two confidence tiers:

Confidence Example field names Severity
High password, passwordHash, ssn, creditCard, cvv, apiKey, secret, privateKey, stripeCustomerId, access_token, refresh_token High
Medium internalNote, internal_id, tax_id, vat_number, phone_number, billing_address, date_of_birth Medium

Common false positives: fields named token that aren't auth tokens (pagination or CSRF tokens), sandbox data that happens to match the patterns, and self-service fields like a user's own apiKey. Use personas with a clear privilege gap and review matches in context.

API4 — Unrestricted Resource Consumption (api4-resource-consumption)

No personas required. Three probes.

Probe What it does Severity
Unbounded pagination Sends collection GET endpoints ?limit=999999&pageSize=999999. If the endpoint returns 2xx instead of a 400 or a capped page, it flags the endpoint. High
Oversized payload Sends POST endpoints a large JSON body (the profile's Max probe payload size, ~1 MB by default). A 2xx (accepted) or 5xx (crashed) response is flagged; a healthy server should reject it with 413 Payload Too Large. High
Rate-limit burst (opt-in) Fires a short burst of rapid GET requests at the first collection endpoint. If it never sees a 429 Too Many Requests, it flags the endpoint. Runs only when the profile's Enable rate-limit probe toggle is on (off by default, because a burst can stress a shared target). Medium

The oversized-payload size and the rate-limit-burst opt-in are both set on the scan profile — see Scan profiles.

Common false positives: APIs that silently cap results regardless of the requested limit, and endpoints designed to accept large bodies (file upload, bulk import). A gateway that rate-limits at the edge above the burst threshold also hides the burst probe.

API5 — Broken Function Level Authorization (api5-bfla)

Personas: 1 or more required.

The BFLA scanner classifies endpoints as "admin" by path heuristic — paths containing /admin, /internal, /management, /manage, /system, /superuser, /sudo, or /root (and, once present, spec tags naming those areas). It then calls each admin-looking endpoint using the assigned normal-user persona. Any 2xx response is a Critical finding, because a non-admin reached an admin function; 400/401/403/404 are treated as the endpoint correctly rejecting the request.

Common false positives: endpoints with admin in the path that are intentionally public (/admin/health), and feature names that happen to contain "admin". Pick a spec scoped to the surface you actually want tested.

API6 — Unrestricted Access to Sensitive Business Flows (api6-business-flow)

No personas required. The scanner flags state-changing endpoints (POST, PUT, PATCH, DELETE) whose path or spec tags identify them as a sensitive business flow — matching keyword tokens such as checkout, purchase, order, payment, transfer, signup, register, invite, redeem, coupon, vote, subscribe, and similar.

The probe is deliberately passive: it sends a single OPTIONS request per matched endpoint — never the real write, which would trigger the flow — and inspects the response headers for rate-limit signalling (Retry-After, X-RateLimit-*, RateLimit-*). If none are present, it raises a Medium, low-confidence finding: the absence of those headers is a hint, not proof, that the flow is unthrottled and open to automation abuse (scalping, spam, coupon abuse, credential stuffing). No burst or flood probe is performed here — that DoS-shaped check lives behind the opt-in in api4-resource-consumption.

Common false positives: flows protected by rate-limiting, bot detection, or step-up challenges that don't surface a rate-limit header on an OPTIONS response, and endpoints whose path merely contains a keyword without being a real flow. Treat every finding as a prompt for a manual check.

API7 — Server-Side Request Forgery (api7-ssrf)

No personas required.

This scanner inspects POST and PUT request body schemas for URL-shaped fields — property names like url, uri, link, callback, webhook, redirect, target, endpoint, host, image, imageUrl, fetch, and src. For each such field it submits a set of SSRF payloads:

Payload Target
http://169.254.169.254/latest/meta-data/ Cloud instance metadata
http://localhost:22 Internal service probing
file:///etc/passwd Local file read

It detects a hit two ways: the response echoes metadata markers (cloud metadata fields, SSH banners, /etc/passwd contents) → Critical finding; or a successful response takes longer than 5 seconds, suggesting the server made an outbound call → Medium, low-confidence finding.

Common false positives: URL fields validated server-side (the scanner can't see the validation), slow responses caused by network latency rather than SSRF, and URL fields the server only stores or displays but never fetches.

API8 — Security Misconfiguration (api8-misconfig)

No personas required. Four checks.

Check What it looks for Severity
Plain HTTP The environment base URL uses http:// instead of https://. High
Security headers Missing Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, or Content-Security-Policy on endpoint responses. Medium
CORS wildcard A response returns Access-Control-Allow-Origin: *. High
Debug endpoints The paths /debug, /trace, /actuator, and /actuator/health respond successfully at the base URL. Medium

Header and CORS checks probe each endpoint (with a HEAD request, falling back to GET); the plain-HTTP check produces a single finding for the whole target.

Common false positives: internal APIs where a CORS wildcard is acceptable, development environments that intentionally expose debug endpoints, and reverse proxies that add security headers above the origin the scanner sees. Point the scan at the proxied URL for accurate header results.

API8 — Legacy TLS Version (api8-tls-version)

No personas required. api8-misconfig can only report plain http://, because the HTTP client hides the negotiated TLS protocol. This scanner fills that gap: it runs a dedicated TLS handshake against the target host once per run and raises a Medium, high-confidence finding only when the host provably completes a handshake using deprecated TLS 1.0 or TLS 1.1. A plain-HTTP base URL is skipped (there's no TLS layer to probe — api8-misconfig already covers it).

TLS 1.0/1.1 are deprecated (RFC 8996) and fail modern baselines such as PCI DSS; the remediation is to disable them at the load balancer or reverse proxy and serve TLS 1.2+ only.

Common false positives: none of note — the finding is only raised on a completed weak-protocol handshake.

API9 — Improper Inventory Management (api9-inventory)

No personas required. Two discovery probes, both raising Medium findings.

Probe What it does
Old versions If the base URL path contains /vN, the scanner requests every lower version (/v{N-1} down to /v0). Any that responds successfully is flagged as a still-reachable old version.
Shadow endpoints Sends OPTIONS to /admin, /api/internal, /health, /metrics, /swagger, and /openapi.json. A path that answers with 2xx, 401, or 403 is flagged as an undocumented reachable endpoint.

Common false positives: intentionally maintained (and patched) old versions, and health/metrics endpoints that are meant to be reachable for monitoring.

Schema/Body Fuzzing (fuzz-schema)

No personas required. Requires Fuzzing intensity above Off in the profile — even when selected, the scanner sends no requests while intensity is Off. See Scan profiles.

For every write endpoint (POST, PUT, PATCH) that declares a request-body schema, the scanner generates mutated bodies from that schema — boundary values, type confusion, format violations, and an injection dictionary, with more payload classes enabled at higher intensity — and looks for three failure classes:

Failure class What it means Severity
server-error A mutated body drove the handler to a 5xx. High
type-leak The response echoed a stack trace or framework error. Medium
missing-validation A payload a spec-compliant server should reject (wrong type, bad format, out of range) was accepted with a 2xx. Medium

Findings are clustered per endpoint + field + error class, so a large payload set produces one finding per real issue rather than a flood. The scanner honours a hard per-scan request cap and the profile's time budget.

Common false positives: endpoints that intentionally coerce loose input, and validation performed downstream that the scanner can't observe.

Mutation Fuzzing (fuzz-mutation)

No personas required. Requires Fuzzing intensity above Off in the profile (same gate as fuzz-schema).

This scanner starts from a valid baseline request, sends it, and — only if the baseline is accepted (2xx) — fires structural mutations of it (dropping or duplicating fields, retyping values, encoding tricks) and diffs each response against the baseline. The baseline comparison is what sets it apart from fuzz-schema: a 5xx here means a mutation broke an endpoint that provably worked a moment earlier. It reports the same three failure classes and severities as fuzz-schema (server-error High; type-leak and missing-validation Medium), clustered the same way, under the same request cap and time budget.

Common false positives: as with fuzz-schema, endpoints with lenient input handling by design.

Not covered

One OWASP API Security Top 10 category has no scanner:

Category Why it isn't automated
API10:2023 — Unsafe Consumption of APIs Requires analysis of the upstream/third-party APIs your service calls, which are outside the scanner's visibility into your API surface.