Test API security: from rule to meaningful test

A testable promise instead of a general seal of approval

‘The API is secure’ leaves the data, users and flows unspecified. A useful promise might be: ‘An ordinary member may read only their team's exports; only the creator may edit drafts; a completed export job is not executed again on retry.’ Expected results can be derived from this.

First write down permitted cases. Some applications allow team sharing, others only personal access. A test indiscriminately prohibiting every record owned by someone else would be wrong where team sharing is intended. Then define negative cases: another identity, missing role, different tenant, forbidden field, invalid state or revoked access.

A permission matrix of caller, resource and action helps. OWASP Authorization Testing Automation describes this approach. Rules must come from your product contract, not merely repeat the code's incidental current behaviour.

A small environment of your own with controllable consequences

Use test identities and synthetic records of known origin. A suitable environment includes layers relevant to the question: authentication, actual application code, an empty test database and, for caching questions, the same proxy type, for example. Use test modes or local substitutes for external services. Real keys and customer data do not belong there.

Before starting, establish possible follow-up actions. An innocent-looking call may trigger emails, webhooks, costs or background jobs. Exclude real recipients, bound quantities and runtime, and use a controlled initial state. Test runs must not accidentally switch to the production address.

Also define cleanup: remove test records or reset the isolated database to its known starting state, revoke test keys and close temporary permissions. If an unexpected external action appears, stop the run and inspect the environment before continuing. Deliberately open or modified negative tests belong in a separate test copy.

Example: testing team exports

The following synthetic example has teams Blue and Green. Lea and Nils are ordinary Blue members, Mara administers Blue, and Sam belongs to Green. All team members may read their team's exports. Only the creator may edit an export while it is a draft. Only a team administrator may delete a completed export. These rules apply solely to the example.

Depending on the API contract, expected rejection may use 403 or a concealing 404. Status alone is insufficient: an application might return an error after making an unauthorised change. Check both response and stored state, plus triggered follow-up work. A test must also establish that the test object exists and the permitted control case works; otherwise an accidentally wrong path may imitate successful rejection.

The articles on BOLA and IDOR, role permissions, field permissions and tenant isolation explain enforcement. Here you combine their rules into repeatable evidence.

Keep important cases in the normal development workflow

Collect test identities, data and expected results in readable fixtures. The following JSON excerpt describes one example test case. Its JSON syntax has been checked; it is not a complete test driver and sends no HTTP request.

{
  "case": "green-member-cannot-read-blue-export",
  "actor": "sam-green-member",
  "resource": "blue-export-01",
  "action": "read",
  "expected": {
    "decision": "deny",
    "containsExportData": false,
    "storedStateChanged": false,
    "jobsCreated": 0
  }
}

The test driver must call the real server-side entry points, use the prepared identity and verify the listed effects. An isolated helper-function test is useful but does not prove every route uses that function. Add suitable integration tests where routing, data access and follow-up actions meet. OWASP Authorization Regression Testing describes retaining such controls through changes.

Choose cases by possible harm and changed behaviour. New export functions need different negative cases from a pure error-text correction. After an authorisation defect is found, retain the relevant regression test. If the business rule deliberately changes, update expectation and rationale together; do not weaken a test merely because it reveals a defect.

Extend the matrix to actual application controls

This selection is no complete test catalogue. For systematic expansion, use suitable requirements from the OWASP Application Security Verification Standard, citing the exact version. Scope and required depth must suit the application. A blanket claim of being ‘OWASP tested’ obscures what was actually examined.

Where a public response probe helps

The API Security Check examines defined public GET/OPTIONS responses and a limited GET error probe. It can interpret visible CORS, method, header or server information, for example. It provides no evidence for your role matrix, tenant isolation or business logic. It does not discover every endpoint in your application either.

Use such a finding for the question it can answer: what was visible at this specified target under the check's conditions? Keep it distinct from authenticated integration tests and configuration review. A result without visible anomalies leaves untested questions open. The HTTP findings guide helps interpret it; reports document the same limited measurement.

Document a result the team can work with

A useful test record names the promise, tested revision, environment, synthetic roles used and observed response with its effect. Secrets do not belong in the report. State specifically what was omitted: an unavailable partner test mode, a browser policy not reproduced or behaviour under concurrent processes not yet tested, for example.

Separate three outcomes: the expectation is supported by evidence, the expectation was violated or the case could not be meaningfully tested. An unreachable endpoint belongs to the third group. A good overall grade cannot replace that state. Fix a concrete defect and repeat the affected case plus closely related permitted flows.

If you must roll back a change, also check the security state restored by it. An old version may work reliably while reintroducing the same known authorisation flaw. Where potential harm is high or major questions remain, plan an independent technical review with clear environment and scope. Product acceptance rests on this evidence and remaining risks; this guide does not grant it automatically.

Next steps