API Security Testing skill for Codex

APIs fail differently from web UIs: the top risks are authorization, not injection. A good test proves, with two accounts and the raw requests, that one user can reach another’s objects or fields, that limits do not hold, and that the client can set fields it should not. Work only inside written scope.

Gate 0 — authorization

Before any request: confirm written authorization, exact in-scope base URLs/endpoints, out-of-scope items, allowed techniques and request-rate limits, the testing window, and an emergency contact. Missing or ambiguous → stop and ask. Full engagement discipline and evidence/cleanup rules are in pentest-methodology. Testing an API needs network access and likely a tool install; Codex’s sandbox may prompt for approval — say so.

Setup

• Get the API contract if it exists: OpenAPI/Swagger, GraphQL introspection, Postman collection, or the client code. Enumerate every endpoint, method, parameter and object ID.
• Obtain two accounts of the same role plus a higher-privilege account. Most API bugs need a second identity to prove.
• Capture a valid request for each endpoint to replay and mutate (curl, HTTPie, Postman, or a proxy like Burp — see burp-suite-workflows).

OWASP API Top 10 (2023) checklist

- [ ] API1 BOLA — object ID from A's request works with B's token
- [ ] API2 Broken authentication — weak/reused tokens, no expiry, JWT alg:none/unsigned, login brute-force
- [ ] API3 Broken object property level auth — mass assignment (set fields you shouldn't) and excessive data exposure (response leaks fields)
- [ ] API4 Unrestricted resource consumption — no rate limit, no pagination cap, huge payloads, expensive GraphQL queries
- [ ] API5 Broken function level auth — low-priv user calls admin-only method/route
- [ ] API6 Unrestricted access to sensitive business flows — automate a flow meant to be human-paced
- [ ] API7 SSRF — endpoint fetches a user-supplied URL
- [ ] API8 Security misconfiguration — verbose errors, permissive CORS, missing headers, HTTP methods
- [ ] API9 Improper inventory — undocumented/old versions (/v1 vs /v2), debug/staging endpoints
- [ ] API10 Unsafe third-party API consumption — trusting upstream responses blindly

High-yield techniques

BOLA (API1) — the number-one API risk. For every endpoint that takes an object ID:

# Capture A's request, then replay the same path with B's token
curl -s https://api.example.test/v1/orders/1001 -H "Authorization: Bearer $A_TOKEN"   # A's order
curl -s https://api.example.test/v1/orders/1001 -H "Authorization: Bearer $B_TOKEN"   # should be 403/404

If B gets A’s object, that is a confirmed BOLA. Try sequential and guessable IDs, IDs in the body and in nested JSON, and IDs in bulk endpoints.

BOPLA (API3). Two sides:

• Mass assignment: add fields the client should not control ("role":"admin", "isVerified":true, "balance":9999, "userId":<other>) to a create/update body and check if they stick.
• Excessive exposure: read a response and look for fields the UI never shows (password hashes, internal flags, other users’ PII) that the server filters client-side only.

Broken function-level auth (API5). Take an admin request, replay with a normal-user token. Try hidden methods (PUT/DELETE where only GET is documented) and /admin routes.

Resource consumption (API4). Request a huge ?limit=, omit pagination, send a large array, or (GraphQL) a deeply nested/aliased query. Confirm whether limits exist — do not run a sustained DoS; one probing request is enough to show the missing cap.

JWT checks (API2). Decode the token; test alg:none, an unsigned/modified payload, an expired token, and a token from a different user/tenant. Confirm the server verifies the signature and claims.

GraphQL specifics

• Check if introspection is enabled in production (should usually be off).
• Test authorization per field/resolver, not just per query — BOLA often hides in a nested resolver that skips the check the top-level query enforces.
• Test query depth/complexity limits with a nested query; batching/aliasing to amplify work.

Confirming and recording

• Minimal proof per finding: the two raw requests (A vs B, or user vs admin) and their responses, timestamped, with tokens and PII masked.
• One-sentence impact each. Rule out false positives (e.g. 404 that is actually enforcement).

Output contract

## API security test — <api> (<window>)
Authorization: <ref>. Scope: <base URLs>. Contract: <OpenAPI/introspection/none>.

### Findings
#### [Critical] API1 BOLA — cross-account order access
`GET /v1/orders/1001` with user B's token returns user A's order (200, full PII).
Evidence: `bola_orders_A_vs_B.txt`.
Remediation: enforce `order.userId == token.sub` server-side; return 404 on mismatch.

### Coverage: <API1–API10 tested/skipped>. Cleanup: <created objects removed>.

Hard rules

• No authorization or out of scope → stop. Keep request rates within the agreed limit.
• Prove missing limits with a single probe; never run a sustained denial-of-service.
• Do not exfiltrate real user data beyond the minimum needed to prove a finding; mask it.
• Delete any objects/accounts you created and confirm removal.