API

API Security Assessment Report

Self-hosted OWASP crAPI lab (intentionally vulnerable training API) on an isolated Docker / VirtualBox network. Not a client system.

2026-09-07 · Public lab sample · no client data

Open PDF Download PDF

Executive Summary · Scope · Methodology · Risk Rating · Findings · Evidence · Impact · Remediation · Retest

Executive Summary

Hands-on testing of a lab crAPI deployment confirmed five API classes that map to the OWASP API Security Top 10: broken object-level authorization on mechanic reports and media, acceptance of forged JWTs, server-side request forgery through a mechanic callback URL, injection on coupon endpoints, and excessive data exposure in identity and community responses. No production systems were in scope. Client reports use the same sections; hosts, tokens, and payloads are omitted from this public sample.

Scope

In scope: REST surfaces under /identity, /community, and /workshop on the lab crAPI instance; JWT user role; cross-user IDOR on reports, videos, and orders; auth and token handling; coupon and shop flows. Out of scope: denial-of-service soak beyond a single Layer-7 proof on the contact-mechanic path, cloud IAM, and mobile clients. Testing window: 6–7 September 2026, lab network only.

Methodology

Mapped routes from the running UI and proxy history, then verified each finding with two lab identities (aov@example.com and peer seed accounts). Object IDs belonging to User B were substituted while holding User A’s token. Authentication tests covered password-reset / OTP handling and JWT algorithm acceptance. Injection and SSRF checks used lab-safe probes only; request/response pairs were retained in Burp and screenshot workpapers. No production data and no destructive wipes of the lab database beyond coupon-state resets required by the challenges.

Risk Rating

API findings are ranked by authorization failure and token integrity first (BOLA, JWT forge), then SSRF and injection, then data exposure. CVSS v3.1 is recorded; executive order follows who can call the endpoint without extra privileges on a multi-tenant SaaS-shaped API.

Findings

Evidence, impact, and remediation sit under each finding — the same order used in client PDFs.

API-01HighCVSS 8.2

Broken object-level authorization on mechanic reports and media

Evidence: With a standard user JWT, changing the report_id query parameter on the mechanic report endpoint returned another user’s vehicle, owner email, and problem details from the lab seed set. The same class appeared on video delete: a caller could remove another user’s uploaded video by object ID. Authentication was present; ownership binding was not.
Impact: Any authenticated caller who can enumerate IDs can read or delete another tenant’s records. In a multi-tenant product this is direct customer data exposure and integrity loss.
Remediation: Authorize every object access against the token subject (and tenant). Prefer opaque IDs. Add regression tests that fail if User A can read or delete User B’s reports and media. Retest GET and DELETE on the same resource families.

API-02CriticalCVSS 9.1

API accepts forged JWTs with a none algorithm

Evidence: Tokens presented with an unsigned / none-algorithm header were accepted by protected workshop and identity routes that should require a verified RS256 signature. Lab requests using a forged subject still received successful JSON responses for authenticated resources. Signature verification was not enforced for that algorithm path.
Impact: An attacker can mint a token for any lab subject without credentials and call authenticated APIs as that user — full account impersonation on the API surface.
Remediation: Reject tokens whose alg is none or otherwise outside an allow-list. Verify signatures with the expected key and algorithm only. Add negative tests for unsigned and algorithm-confused tokens. Retest all bearer-gated routes.

API-03HighCVSS 8.6

Server-side request forgery via mechanic callback URL

Evidence: The contact-mechanic workshop endpoint accepted a client-supplied mechanic_api URL. The lab service fetched that URL server-side and returned the remote body (including a public site) inside the JSON response. The same parameter accepted an internal lab callback, confirming the server initiates the request.
Impact: An authenticated user can coerce the API host to reach internal or third-party URLs, exfiltrate response content, and expand into network-adjacent services — a classic SSRF pattern on APIs that proxy callbacks.
Remediation: Do not accept raw callback URLs from clients. Allow-list destinations, resolve and block private ranges, and strip response bodies from untrusted fetches. Retest with internal and external URL classes.

API-04HighCVSS 8.0

Injection on coupon validation and apply endpoints

Evidence: Coupon apply and validate routes interpreted crafted coupon values as database queries. Lab responses reflected backend version / query errors and, on a separate community validate path, NoSQL operator behavior that altered validation outcome. Confirmed only against the isolated lab database; payloads are retained in private workpapers, not this public sample.
Impact: Injection on shop or coupon APIs can expose schema and data, bypass redemption rules, or escalate to wider database compromise depending on privileges of the API service account.
Remediation: Use parameterized queries and typed ORMs. Reject non-string operator objects in JSON. Add tests for classic and NoSQL injection classes on every coupon and shop write path. Retest apply and validate after hardening.

API-05MediumCVSS 5.3

Excessive data exposure in identity and community responses

Evidence: The user dashboard JSON returned fields beyond what the UI renders (including role and credit). Community recent-posts responses included other users’ email addresses. A video upload response exposed an internal conversion_params property not shown in the product UI. Direct API callers see the full serializers.
Impact: Increases blast radius of a stolen token, aids user enumeration, and leaks internals useful for further IDOR or mass-assignment attempts.
Remediation: Return a dedicated DTO per role and endpoint. Strip unused and internal fields server-side. Review every list and upload serializer for the same pattern.

Retest

Retest covers API-01–API-05 after authorization, JWT verification, SSRF allow-listing, injection hardening, and serializer fixes. Include at least two tenants, GET and write methods, and negative JWT cases. New endpoints require a delta test, not assumed coverage.

Engage

Put your controls under test.

Client reports use this structure with your hosts and evidence under NDA. Public samples omit payloads and live targets.