API Security
Audit API security for "$ARGUMENTS". Inventory all APIs, assess authentication and authorization mechanisms, and evaluate rate limiting, input validation, and error handling practices.
Prerequisites
Read .metapowers/security/$ARGUMENTS/00-govern.md. If this file does not exist, tell the user:
Phase 0 (Govern) has not been completed for "$ARGUMENTS". Run a Govern skill first (e.g., /security:security-policy $ARGUMENTS), or use --skip-checks to bypass.
If --skip-checks is present in $ARGUMENTS, skip this check and log to .metapowers/security/$ARGUMENTS/skip-log.md.
Process
-
Inventory all APIs:
- Catalog internal APIs (service-to-service), external APIs (public-facing), and partner APIs (B2B)
- Document each API's purpose, data sensitivity, and consumer audience
- Identify API specifications (OpenAPI/Swagger, GraphQL schema, gRPC protobuf)
- Note API versioning strategy and deprecated endpoints still active
-
Assess authentication methods:
- Review authentication mechanism per API (OAuth 2.0, API keys, JWT, mTLS, session tokens)
- Verify token validation (signature verification, expiration checks, audience validation)
- Check API key management (generation, rotation, revocation, scoping)
- Identify unauthenticated endpoints and confirm they are intentionally public
- Evaluate OAuth 2.0 flows used (authorization code with PKCE preferred over implicit)
-
Review authorization checks:
- Verify authorization is enforced at every endpoint (not just at the gateway)
- Check for object-level authorization (users can only access their own resources)
- Review function-level authorization (admin endpoints restricted to admin roles)
- Assess GraphQL-specific risks (nested query depth, introspection in production)
- Look for mass assignment vulnerabilities (binding request body directly to data models)
-
Evaluate rate limiting:
- Verify rate limiting is configured per API and per consumer
- Check rate limit differentiation by endpoint sensitivity (login endpoints, data export)
- Review rate limit response behavior (429 status code, Retry-After header)
- Assess protection against distributed attacks (per-IP and per-account limits)
-
Review input validation and error handling:
- Verify request body, query parameters, and headers are validated against schema
- Check for injection risks in API parameters (SQL, NoSQL, command injection)
- Confirm error responses do not leak internal details (stack traces, database errors, internal IPs)
- Review pagination to prevent data enumeration and excessive data retrieval
-
Assess CORS and transport security:
- Review CORS configuration (no wildcard origins for authenticated APIs)
- Verify HTTPS-only enforcement with HSTS headers
- Check for sensitive data in URL query parameters (should be in headers or body)
- Review API gateway security configuration if applicable
-
Write the artifact to .metapowers/security/$ARGUMENTS/02-protect.md with heading:
API Security Audit
Include sections:
- API Inventory — all APIs with type, authentication method, and data sensitivity
- Authentication Assessment — findings per API on auth mechanism strength
- Authorization Review — object-level and function-level authorization coverage
- Rate Limiting — current configuration and gaps
- Input Validation — validation coverage and injection risks
- CORS and Transport — configuration findings
- Remediation Plan — prioritized fixes by severity
Output
The API security audit written to .metapowers/security/$ARGUMENTS/02-protect.md. Present a summary to the user highlighting:
- Total APIs inventoried by type and sensitivity
- Authentication and authorization gaps found
- Rate limiting coverage
- Top priority remediations