REST API security testing: every method, every field, every caller.
REST makes APIs predictable: resources in the path, verbs in the method, state in the body. That predictability is what attackers rely on. This guide breaks a REST request into the parts that get attacked, lists test cases for each HTTP method, and shows what a secure response looks like.
REST API Security Test Cases for Every HTTP Method
Each verb carries its own risks. Pick a method to see what to test, the request to send and the response a secure API returns.
REST API Security Test Run: Expected vs Actual on One Resource
Ten tests against /v2/accounts/{id}, run as three identities. A test passes when the actual response matches the secure one. Watch which status codes give the flaws away.
Illustrative run · synthetic API and data · 20 s replay
Mass Assignment Example: One Extra Field in a PATCH
The profile endpoint binds the request body straight onto the user model. The UI never sends role, so nobody noticed the API accepts it.
How to prove API endpoint abuse →Illustrative finding · synthetic data
REST API Status Codes: What a Secure Response Looks Like
Test assertions should name the exact code. A 200 where a 404 belongs is a finding, and so is an error that leaks more than it should.
No credentials, or credentials that are invalid or expired.
RED FLAG · 200 with a missing or expired token.Valid caller, but this role may not perform this function.
RED FLAG · Used for other users' objects, confirming they exist.Object doesn't exist, or exists but belongs to someone else.
RED FLAG · 200 for another tenant's object.Unknown, protected or malformed fields in the body.
RED FLAG · 200 that silently accepts protected fields.A verb or override the resource doesn't support.
RED FLAG · Override headers that change the method.Body beyond the documented maximum.
RED FLAG · Large bodies parsed before being rejected.Caller or target exceeds its rate limit.
RED FLAG · No limit on login, invite, OTP or export.Should be rare, and generic when it happens.
RED FLAG · Stack traces, SQL or internal hostnames in the body.How to Test a REST API: From OpenAPI Spec to CI
Six steps that turn one-off testing into a suite that runs on every pull request.
Choosing an API security testing tool →Reconcile spec and traffic
Compare the OpenAPI spec with real traffic and gateway routes. Undocumented endpoints are often the least protected.
Define identities
At least two users per role across two tenants, plus anonymous. Keep their tokens fresh automatically.
Model ownership and writable fields
Record who owns each seeded object and which fields each role may write. The spec doesn't say.
Generate method-level tests
Expand each endpoint into the tests on this page for every method it supports, plus overrides.
Assert exact responses
Name the expected status code and allowed fields for each test. A 200 is not a pass by default.
Run in CI and retest
Run on every pull request that touches routes or models; failures block merge, fixes rerun automatically.
REST API Validation That Knows Who's Calling
Hayrok reads your OpenAPI spec and live traffic, runs the method-level tests on this page as every identity you define, and asserts on ownership and exact status codes. Each failure is a validated finding with the request pair attached.
Spec plus traffic
Builds the endpoint inventory from your OpenAPI spec and observed traffic, flagging the difference.
Every method, every identity
Runs method-level scenarios as each role and tenant, including verb overrides.
Ownership-aware assertions
Knows which identity owns each test object, so a cross-tenant 200 is a failure.
Safe writes
PUT, PATCH and DELETE run only on seeded test objects inside approved scope.
Evidence in CI
Failures post to the pull request with the request pair; Evidence Fabric keeps the record.
REST API Security Testing FAQ
Testing a REST API the way an attacker would: changing object IDs, adding fields, switching HTTP methods, calling as different users and pushing limits, then checking that every response is the secure one.