They should encode negative tests for state changes, repeated actions, and out-of-order requests that would only succeed if the API authorises too much. Those checks belong in the same CI path as functional tests so teams see security failures before merge or promotion. The goal is to prove that the API enforces business rules under realistic test conditions.
How CI testing should prove API access rules, not just happy-path behaviour
CI is the right place to prove that an API refuses actions it should not allow, not only that it accepts valid requests. The strongest tests focus on business-rule abuse cases: duplicate submissions, state changes that arrive twice, and requests sent in the wrong sequence. If the API authorises too much, those tests should fail before merge or promotion.
Good coverage treats access rules as executable policy. A passing functional test only shows that a route works with expected input; a security-relevant CI test shows that the same route still blocks invalid actor behaviour, unsafe repetition, and replay-like sequences. That distinction matters most when the API drives money movement, account changes, entitlements, approvals, or other stateful operations.
Teams should aim to test the decision points where authorisation can drift: object ownership, state transition rules, action frequency, and whether one request can create a later privilege-bearing condition. For APIs, those are often more important than generic input validation because the risky failure is not malformed data, but an accepted action that should have been denied.
Test cases that expose excessive API authorisation
The most useful CI cases are negative tests that mirror real misuse patterns. Send the same state-changing request twice and confirm the second attempt is rejected or safely ignored. Try repeating an approval, cancel, transfer, or update in a way that would only work if the API failed to enforce idempotency or business-state checks. Then send requests out of order, for example trying to finalise before create, approve before submit, or modify an object that the caller does not own.
These tests should also cover object scope. A caller that can access one record should not be able to infer or manipulate another record by changing an identifier, especially when the API exposes predictable IDs, sequential references, or nested resources. That is the core of access-rule testing: proving that the server makes its own decision about what the caller may do, rather than trusting the client to stay honest.
When the application uses tokens, scopes, or delegated access, the same CI path should verify that a valid credential does not imply broad rights. A token can be authenticated and still be over-authorised. For that reason, authorisation tests belong beside authn and functional tests, not as a separate manual review step after release.
How to structure CI checks so they fail for the right reasons
Good CI tests are deterministic, environment-safe, and close to the real enforcement path. They should call the same API endpoints, use realistic test identities and fixtures, and assert on the actual denial signal, whether that is a 403 response, a rejected workflow state, or the absence of a side effect. If the test only inspects client-side validation or mocks the policy engine, it can miss the defect that matters.
For stateful APIs, the setup and teardown need to leave the system in a known condition so repeated pipeline runs are trustworthy. Teams should isolate the negative test data, reset mutable objects between runs, and make the expected final state explicit. That reduces false positives and helps reviewers see whether a failure reflects a security regression or a bad test dependency.
These checks become especially valuable when paired with transportable security test patterns and supply-chain controls. For build and release assurance around the pipeline itself, teams can also review SLSA alongside API access tests so they are not only verifying the application behaviour, but also the integrity of the path that delivers it.
Risk and Threat Considerations
APIs that over-authorise requests create a direct path to data loss, unauthorised state change, and privilege abuse. The danger is often subtle because the request is syntactically valid and may even look harmless in a normal functional test. The failure only appears when the API is asked to repeat, reorder, or expand a permitted action beyond the intended business rule.
Failure mechanism: The API accepts a request that should have been denied because it trusts request shape, sequence, or caller intent more than server-side authorisation and state validation. Attackers and misuse cases then turn one permitted action into many, or convert a low-risk operation into a higher-impact change.
Impact: Excessive access can enable duplicate charges, repeated approvals, record tampering, cross-account access, and bulk abuse at machine speed. Once such a gap reaches production, remediation usually requires rollback, revocation, or compensating controls, not just a code fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | API access rules and business-action enforcement are central to this testing question. |
| API1 — Broken Object Level Authorization | Object-boundary checks matter when requests can target other records or IDs. | |
| API6 — Unrestricted Access to Sensitive Business Flows | Repeated or out-of-order actions can bypass intended business-flow restrictions. | |
| Recommendation — Add CI tests that prove forbidden API actions are denied at the function level. Test that changing object identifiers does not grant access to another user's data. Exercise stateful workflows in CI and block replay, duplicate, or reordered actions. | ||
| OWASP ASVS | V8 — Authorization | CI should verify server-side authorisation decisions for protected operations. |
| Recommendation — Automate negative authorization tests for protected API operations in the pipeline. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Excessive API access is fundamentally a least-privilege failure. |
| IA-5 — Authenticator Management | CI often uses tokens or secrets whose handling affects API test validity and exposure. | |
| Recommendation — Verify that API identities can perform only the minimum required operations. Use short-lived test credentials and rotate or revoke them after pipeline use. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Testing API access rules supports continuous validation of account and permission control. |
| Recommendation — Continuously test and review API access paths against intended permissions. | ||
| SLSA | Supply chain levels for software artifacts | CI pipeline trust and release integrity shape whether security test results are reliable. |
| Recommendation — Protect the pipeline so the access tests you run are attached to trusted build artifacts. | ||
Practitioner Guidance
What to prioritise: Put the highest-value negative tests around state-changing endpoints, especially where a second request, reordered request, or modified object ID could cause material impact. Those are the cases most likely to reveal whether the server truly enforces the business rule.
What to verify: Confirm that each test fails on the server-side decision, not because a client library rejects the call or a mock returns a denial. The useful signal is a real refusal from the API under conditions that otherwise look valid.
Common mistake: Teams often cover happy-path functionality and call it API validation, while never proving that the same endpoint rejects repeated or out-of-order requests. That leaves a blind spot where the system works correctly until someone asks it to do one thing too many times.
Practitioner takeaway: Treat CI as the place where you prove the API enforces business authority, not just request syntax; if a request can succeed twice, out of order, or across the wrong object boundary, the control is not yet real.
Related resources from NHI Mgmt Group
- How should security teams secure GitLab access from CI/CD pipelines?
- How should security teams implement API security testing in CI/CD pipelines?
- How should security teams implement access control lists in CI/CD pipelines to avoid privilege creep and pipeline tampering?
- How should security teams implement attribute-based access control in CI/CD pipelines without breaking delivery speed?