APP-011 API Security
Description
All externally-exposed and internally significant APIs are inventoried and subject to defined security controls. Controls include authentication and authorisation on every endpoint, rate limiting, input validation, and prohibition of sensitive data in query parameters or error responses. API security is included in the development security testing scope.
Rationale
APIs are the primary attack surface for AI products and the services that deliver them. Unauthenticated or improperly authorised APIs are among the most commonly exploited vulnerabilities in cloud-native systems.
Applicability (9 profiles)
Framework Mappings (13)
| AIS-08 | API Security | full |
| AIS-09 | Input Validation | partial |
| AIS-08 | API Security | full |
| 8.26 | Application security requirements | informative |
| AML.M0004 | Limit AI Service Query Volume and Rate | informative |
| AML.M0019 | Control Access to AI Models and Data in Production | informative |
| AC-14 | Permitted Actions Without Identification or Authentication | partial |
| SC-6 | Resource Availability | informative |
| SI-10 | Information Input Validation | partial |
| SI-11 | Error Handling | full |
| ASI07 | Insecure Inter-Agent Communication | partial |
| LLM10 | Improper Output Handling | partial |
| CC6.6 | Security Measures Against Threats Outside System Boundaries | informative |
Evidence (2)
API gateway or application configuration showing that authentication, authorisation, and rate limiting are enforced on all externally-exposed API endpoints.
Example: AWS API Gateway authoriser configuration, Kong API Gateway policy export, or application-level middleware configuration showing: authentication type (OAuth 2.0, API key, JWT) required on every route, rate limit settings (requests per second/minute), and input validation middleware enabled.
Test: Review the API gateway or application routing configuration. Verify: (1) every external-facing endpoint has an authentication requirement, and no unauthenticated routes exist except for explicitly public endpoints with documented justification, (2) rate limiting is configured at the gateway or application layer with specific thresholds, (3) sensitive data fields (passwords, tokens, PII) are absent from query parameters and are not reflected in error responses, confirmed by reviewing a sample of API specifications (OpenAPI/Swagger).
API security scan or DAST report confirming that the API inventory is complete and that common API vulnerabilities (OWASP API Security Top 10) are addressed.
Example: OWASP ZAP, Burp Suite, or 42Crunch API security audit report for the production or pre-production API, run within the last 90 days, showing: API endpoints discovered, test coverage, and finding list with no open high/critical items from the OWASP API Security Top 10.
Test: Review the most recent API security scan report. Verify: (1) the scan covers all endpoints in the API inventory, cross-referencing the discovered endpoint count against the OpenAPI specification, (2) no open high/critical findings relating to OWASP API Top 10 categories (Broken Object Level Authorisation, Broken Authentication, Excessive Data Exposure, etc.) remain unresolved, (3) the scan was run on the current production version or a staging environment built from the same artefact.
Questions (2)
Are all externally exposed and internally significant APIs subject to a defined set of security controls?
Authentication and authorisation must be enforced on every endpoint. Unauthenticated routes should be the exception with documented justification, not the default. Sensitive data must not appear in query parameters or error responses.
Which API security controls are implemented in your production environment?
Authentication, object-level authorisation, and rate limiting are the three most impactful controls for preventing the most common API vulnerabilities (OWASP API Top 10).