API Penetration Test Report Sample
See exactly what an Operator report looks like, with nothing gated behind a demo. Below is an illustrative sample, run against the open-source crAPI application, showing how every finding carries a CVSS v3.1 vector, request and response evidence, reproduction steps, and remediation.
Illustrative sample, run against the open-source crAPI application
This page is an illustrative sample, run against the open-source crAPI application, a deliberately vulnerable API published by the OWASP community for training. It uses safe, non-customer data to demonstrate the structure and depth of an Operator report. It does not represent any real customer engagement.
crAPI (open source)
The Completely Ridiculous API, an OWASP training target with intentional BOLA and BFLA flaws. Base URL shown as api.crapi.example for clarity.
Spec-driven, multi-identity
Every operation enumerated from the spec, tested with two authenticated accounts to reveal cross-account and function-level access.
OWASP API Top 10, CVSS v3.1
Findings are classified against the OWASP API Security Top 10 and scored with CVSS v3.1 vectors.
Findings at a glance
Three illustrative findings from the sample run, ordered by severity. Each is detailed below with full evidence.
| # | Finding | OWASP | Severity (CVSS v3.1) |
|---|---|---|---|
| 1 | BOLA: cross-account access to another user's order | API1:2023 | High, 8.1 |
| 2 | BFLA: standard user reaches an admin-only endpoint | API5:2023 | High, 7.7 |
| 3 | BOLA: cross-account read of vehicle location | API1:2023 | Medium, 6.5 |
BOLA: cross-account access to another user's order
OWASP API1:2023 (Broken Object Level Authorization). Severity High. CVSS v3.1 base score 8.1, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. A standard user can read another user's order object, including shipping and payment metadata, by substituting the order identifier.
Evidence. Authenticated as user A, requesting an order owned by user B. Sensitive values redacted.
GET https://api.crapi.example/workshop/api/shop/orders/1042 HTTP/1.1
Host: api.crapi.example
Authorization: Bearer <user-A-token>
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 1042, "user": { "email": "user-b@[redacted]", "number": "+1[redacted]" },
"quantity": 1, "status": "delivered", "credit_card": "**** **** **** [redacted]" }
Reproduction.
- Authenticate as user A and note that A owns order 1039.
- Send a GET to /workshop/api/shop/orders/1042, an order owned by user B, with A's bearer token.
- Observe a 200 response containing user B's order and contact details.
- Confirm with A's own token that order 1042 was never associated with A.
Remediation. Enforce object-level authorization on the server: scope the order lookup to the authenticated user, so a request for an order the caller does not own returns 404 or 403. Do not rely on the client to request only its own identifiers. See BOLA testing.
BFLA: standard user reaches an admin-only endpoint
OWASP API5:2023 (Broken Function Level Authorization). Severity High. CVSS v3.1 base score 7.7, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N. A standard user can call an administrative endpoint that lists all orders across users, an operation intended for privileged roles only.
Evidence. Authenticated as a standard user, invoking an admin-scoped listing.
GET https://api.crapi.example/workshop/api/shop/orders/all HTTP/1.1
Host: api.crapi.example
Authorization: Bearer <standard-user-token>
HTTP/1.1 200 OK
Content-Type: application/json
{ "orders": [ { "id": 1039, "user": "user-a@[redacted]" },
{ "id": 1042, "user": "user-b@[redacted]" }, ... ], "count": 214 }
Reproduction.
- Authenticate as a standard, non-admin user.
- Send a GET to /workshop/api/shop/orders/all with the standard user's token.
- Observe a 200 response listing orders belonging to many users.
- Confirm the endpoint is documented and intended as admin-only.
Remediation. Enforce function-level authorization at the endpoint, checking the caller's role on the server before serving the response, not only in the UI. Deny by default and grant the listing only to roles that are explicitly permitted. See BFLA testing.
BOLA: cross-account read of vehicle location
OWASP API1:2023 (Broken Object Level Authorization). Severity Medium. CVSS v3.1 base score 6.5, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. A user can read the last known location of a vehicle registered to another user by substituting the vehicle identifier.
Evidence. Authenticated as user A, requesting a vehicle owned by user B.
GET https://api.crapi.example/identity/api/v2/vehicle/9f2c-[redacted]/location HTTP/1.1
Host: api.crapi.example
Authorization: Bearer <user-A-token>
HTTP/1.1 200 OK
Content-Type: application/json
{ "vehicleId": "9f2c-[redacted]", "vehicleLocation": { "latitude": "[redacted]", "longitude": "[redacted]" } }
Reproduction.
- Authenticate as user A with a vehicle of A's own.
- Obtain a vehicle identifier belonging to user B.
- Send a GET to /identity/api/v2/vehicle/{B-vehicleId}/location with A's token.
- Observe a 200 response disclosing user B's vehicle location.
Remediation. Bind vehicle records to their owner and enforce that binding on every location request, returning 403 or 404 for vehicles the caller does not own. Treat the identifier as untrusted input, not as proof of ownership.
Common questions about the report sample
Is this a real customer report?
No. This is an illustrative sample, run against the open-source crAPI application, a deliberately vulnerable API published by OWASP for training. It shows the structure and depth of an Operator report using safe, non-customer data. No real customer engagement is represented on this page.
What is in an Operator finding?
Each finding includes a title, a severity with a CVSS v3.1 vector, the exact request and response that demonstrate the flaw (redacted where sensitive), step-by-step reproduction, and remediation guidance. Because the evidence is reproducible, your engineers can confirm the finding and verify the fix on retest.
Why test against crAPI?
crAPI, the Completely Ridiculous API, is an open-source project maintained by the OWASP community specifically to demonstrate common API flaws such as BOLA and BFLA. It is a safe, public target, which makes it ideal for showing what an Operator report looks like without exposing any real system.
Is the Operator report gated behind a demo?
No. This sample is un-gated, and your own First Scan is free and self-serve: a full agentic penetration test that tests every operation and proves each finding, with no demo or quote required. Pricing model published (per API, by endpoint volume); free First Scan; final price quoted.
Get a report like this for your own API
Your First Scan is free: a full proven pentest of your API, no demo required. See also the proof behind every finding.