Phase 6 · OWASP API Security Top 10 (2023) · Lesson 3 of 3
Find the OWASP API Top 10 Flaws in a Mock API
Exercise
·
25 min
·
+20 pts
This is the core skill of an API security review: read the spec and the endpoint behaviors, and spot where a control is missing. Below is the API for PayLoop, a small B2B invoicing product. Six flaws have been seeded into it. For each, identify the OWASP API Top 10 category, then write the remediation and the evidence you would collect to prove it is fixed.
Work through the spec first, then answer the six quizzes, then write up the remediation.
The PayLoop API (excerpt)
AUTH
POST /v3/login email + password -> returns JWT (no limit on attempts)
JWT verification: library configured to accept the token's own "alg" header
INVOICES
GET /v3/invoices/{id} returns invoice {id}; requires a valid JWT (any logged-in user)
GET /v3/invoices?limit={n} returns n invoices; n has no maximum
PATCH /v3/users/{id} updates a user; binds the entire JSON body to the user record
ADMIN
POST /v3/admin/refund issues a refund; requires a valid JWT (role not checked)
INTEGRATIONS
POST /v3/preview body: { "url": "..." }; server fetches the URL and returns a preview
INVENTORY NOTE
/v1/invoices still live in production (pre-auth-rewrite), undocumented, unmonitoredPayLoop API — endpoints and observed behavior
Flaw 1: GET /v3/invoices/{id}
Quick check
GET /v3/invoices/:id returns the invoice to any logged-in user, with no check that the caller owns it. An attacker changes the id and reads other companies' invoices. Which category?
Flaw 2: JWT verification
Quick check
PayLoop's JWT library is configured to accept the algorithm declared in the token's own header — so an attacker can forge a token with alg:none and skip signature verification. Which category?
Flaw 3: GET /v3/invoices?limit={n}
Quick check
The list endpoint honors any limit value, including ?limit=10000000, with no maximum and no pagination cap — one request can pull the entire dataset and strain the database. Which category?
Flaw 4: PATCH /v3/users/{id}
Quick check
The update endpoint binds the entire request body to the user record, so a normal user can set the role field to admin on a profile update and escalate their privileges. Which category?
Flaw 5: POST /v3/admin/refund
Quick check
The refund endpoint requires a valid JWT but never checks the caller's role, so any authenticated user can issue refunds. Which category?
Flaw 6: POST /v3/preview
Quick check
The preview endpoint fetches whatever URL the caller supplies. An attacker sets the url to the cloud metadata address http://169.254.169.254/latest/meta-data/ and the server returns cloud instance credentials. Which category?
When the webhook 'preview URL' happily fetches 169.254.169.254
Bonus observation: the /v1/invoices note
The inventory note — an undocumented, unmonitored /v1/invoices still live on production data after the v3 rewrite — is API9: Improper Inventory Management. Keep it in mind for the write-up below; forgotten old versions are where attackers go first.
Write it up: remediation and evidence
Pick three of the six flaws and write the remediation and the evidence you would collect to prove each is fixed. This is the deliverable a reviewer hands back after an API assessment.
Exercise
~10 min
Remediate three PayLoop findings
OWASP API Security Top 10 (2023) Finding
Remediate and evidence three PayLoop API findings
ID:
API-OWASP-6.2.2
Criterion:
Each finding mapped to a category, a fix, and verifiable evidence
Severity:
Mixed (BOLA/BFLA are high)
For three of the six seeded flaws, state the OWASP category, the remediation, and the evidence that proves it is fixed.
Auditor Notes
BOLA (API1): add per-object ownership/tenant authorization on GET /invoices/{id}; evidence = the authZ check + an automated test that another tenant's id returns 403/404. Broken Auth (API2): pin the accepted JWT algorithm server-side, reject alg:none/unsigned, add login rate limiting; evidence = token policy + verifier config + rate-limit config. Resource consumption (API4): cap page size + paginate; evidence = gateway/handler max-limit config + spend/latency alerts. Mass assignment (API3): allow-list updatable fields per role; evidence = serializer/DTO + test that role cannot be set by a normal user. BFLA (API5): require admin role on /admin/refund, deny by default; evidence = endpoint-role matrix + 403 test. SSRF (API7): allow-list outbound URLs, block 169.254/private ranges, no internal redirects; evidence = validation logic + test hitting an internal range is blocked.
Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.
What to carry forward
An API security review is this exercise at scale: read each endpoint, ask the ten OWASP questions, and for every gap name the category, the fix, and the evidence. The most valuable findings are almost always the authorization ones — BOLA, BFLA, and mass assignment — because they let an authenticated, "legitimate" caller reach what isn't theirs. The next module covers where many of these controls get enforced in one place: the API gateway, rate limiting, and key lifecycle.