Both, but governance has to lead. Development teams need fast feedback on function, performance, and integration, while IAM teams need assurance that the same endpoints enforce identity, scope, and data-boundary rules. Once APIs carry critical access decisions, testing becomes evidence of governance, not just code quality.
Why API Testing Belongs in Both Development and Governance
api testing sits in both camps because it serves two different questions. Development asks whether the endpoint works, behaves well under load, and integrates cleanly. Governance asks whether the endpoint allows the right caller, enforces the right scope, and protects the right data boundary. When an API makes access decisions, test results become control evidence, not just quality assurance.
The boundary is practical, not philosophical. A unit or integration test can prove a response code, but it does not by itself prove that privilege checks, object-level restrictions, or token handling are correct across every route. IAM teams care because an API can be functionally correct and still expose data or actions outside policy.
That is why governance should lead the testing agenda. Development can own fast feedback loops and regression coverage, while governance defines the access decisions, the required assertions, and the evidence that must exist before an endpoint is treated as trustworthy. The stronger the API’s role in authentication, authorization, or data access, the more the test plan becomes part of the control environment.
What IAM Teams Need API Tests to Prove
IAM-focused API testing should answer whether the endpoint enforces identity, scope, and privilege as designed. The most important checks are often not “does it respond” but “does it deny the wrong caller,” “does it limit access to the intended object or tenant,” and “does it return only the data the caller is entitled to see.” That makes the test suite part of access governance.
For APIs that support delegation, token exchange, or service-to-service calls, tests should also verify that the accepted trust path matches policy. A weak test can miss overbroad scopes, broken object-level authorization, insecure defaults, or privilege carried across environments. The point is to validate the real authorization decision, not just the happy path.
In practice, this means IAM teams should insist on tests that map to access policy, entitlement boundaries, and sensitive flows. If the API is part of an access-control chain, the absence of explicit negative tests is a governance gap, not only a development gap.
How to Split Ownership Without Splitting Accountability
Ownership works best when development owns execution and IAM owns acceptance criteria. Development should build and run tests continuously, because feedback needs to be fast enough to prevent broken releases. IAM or platform governance should define the mandatory scenarios for identity, scope, and boundary enforcement, then require those results as release evidence.
A useful division is: development validates reliability and implementation correctness; governance validates policy correctness and blast-radius control. The same test can serve both audiences, but the approval standard is different. A passing build is not the same thing as a passing control.
OWASP API Security Top 10 is a good reference point for the kinds of failures that make this split necessary, especially broken authorization and insecure API exposure. For broader cloud identity control, the CSA Cloud Controls Matrix gives IAM and control teams a governance-friendly way to align testing with control expectations. Identity Security Programme Guide helps teams formalise that split across governance, engineering, and evidence ownership.
Risk and Threat Considerations
API testing becomes a security issue when teams assume functional success means policy enforcement is correct. The failure mode is especially dangerous for APIs that expose administrative functions, customer records, or token-backed service access, because a single missed authorization check can create broad data exposure or unauthorized action at scale.
Failure mechanism: Weak test coverage misses broken object-level authorization, scope creep, or overprivileged service access, so an endpoint passes development checks while violating access policy in production.
Impact: Attackers or unintended callers can reach data and actions that should remain outside their entitlement, creating breach, fraud, and lateral movement risk, plus weak audit evidence after the fact.
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 CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 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 testing must prove endpoints enforce intended action-level access. |
| API1 — Broken Object Level Authorization | The question centers on proving APIs do not expose unauthorized objects or records. | |
| API2 — Broken Authentication | Governance-led API testing must confirm callers are authenticated as expected. | |
| Recommendation — Add tests that block unauthorized functions and verify privilege boundaries on protected endpoints. Test object access rules across users, tenants, and tokens to catch BOLA before release. Verify API authentication paths, token validation, and rejection of invalid credentials. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The issue is governance over API identity, access, and authorization controls in cloud environments. |
| Recommendation — Align API test requirements to IAM control objectives and evidence needs. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | API tests should validate that endpoints enforce least privilege and do not overgrant access. |
| AU-2 — Event Logging | Governance over API testing depends on auditable evidence that access checks were exercised. | |
| Recommendation — Test that each API path returns only the permissions needed for the caller's role or scope. Capture test evidence and logs that demonstrate authorization decisions and denied requests. | ||
Practitioner Guidance
What to verify: Require explicit negative tests for unauthorized caller, wrong tenant, wrong object, and excessive scope cases. If a test only proves the “allowed” path, it is not enough for governance sign-off on an access-bearing API.
Decision rule: If the API can grant, deny, or scope access, treat the testing artefact as control evidence and make release approval contingent on those assertions passing. If the API is purely internal utility logic, development can own the suite with lighter governance oversight.
Practitioner takeaway: The key question is not who writes the test, but whether the test proves the access decision the business is actually relying on.