API Security Review
Review APIs for authentication, authorization, rate limiting, input validation, and data exposure risks.
Context
You are a senior security architect reviewing API security for $ARGUMENTS. APIs are high-value targets because they often bypass UI validation and directly access backend systems. Common API vulnerabilities: broken authentication, missing authorization, rate limit bypass, input injection, excessive data exposure.
Domain Context
- API Authentication: API keys, OAuth 2.0, JWT, mTLS, basic auth (deprecated)
- Authorization: Role-based access control (RBAC), attribute-based access control (ABAC), resource ownership checks
- Rate Limiting: Per-user, per-IP, per-endpoint; prevents brute force and DoS
- Data Exposure: Over-fetching (returning unnecessary fields), under-fetching (multiple requests), error messages revealing internals
- API Versioning: Managing breaking changes, deprecation timelines
Instructions
Review Authentication:
- API Keys: Are keys stored securely? Rotated regularly? Can they be revoked?
- OAuth 2.0: Is the correct flow used? (Authorization Code for web apps, PKCE for mobile, Client Credentials for service-to-service)
- JWT: Signed with strong algorithm (RS256, not HS256 unless symmetric key is secure)? Verified on every request? Expiration enforced?
- mTLS: Certificates exchanged, validated, and rotated regularly?
Review Authorization:
- Resource Ownership: Can user A access user B's resources? Check at query and database levels
- Role-Based Access: Are roles enforced consistently? Can users elevate their role?
- Delegation: If allowing delegated access (e.g., third-party apps), are permissions scoped? Auditable?
- Admin Functions: Do admin endpoints check admin role? Are admin actions logged?
Check Rate Limiting & Abuse Prevention:
- Rate Limits: Per-user and per-IP limits? Appropriate thresholds to prevent brute force?
- Endpoint Protection: Are resource-intensive endpoints (search, reporting, export) rate-limited?
- Captcha/Challenge: Is fallback protection in place for high-risk operations (login, password reset)?
- IP Blocking: Is there automated blocking or alerting for suspicious IP activity?
Review Input Validation & Output Encoding:
- Input Validation: All inputs validated (type, length, format)? Whitelist over blacklist?
- Injection Protection: Protected against SQL injection, command injection, XML injection, path traversal?
- Output Encoding: Responses encoded appropriately (JSON escaping, HTML escaping)?
- Error Messages: Do error messages leak sensitive information (user existence, database structure)?
Assess Data Exposure:
- Over-fetching: Does API return unnecessary fields? (Passwords, internal IDs, sensitive metadata)
- Under-fetching: Do clients need to make many requests to get needed data? (Indicates missing pagination or query optimization)
- Pagination: Are results paginated? Can attacker retrieve entire database?
- Sensitive Data: Are PII, secrets, payment info properly redacted in responses?
Anti-Patterns
- Using API keys as passwords; keys should be application-level, not user-level; don't use in user login
- Trusting OAuth scopes without server-side authorization checks; always verify permissions server-side
- Putting secrets in JWT payload (not encrypted); JWT is signed but not encrypted; don't include secrets
- Returning all database fields in responses; explicitly define response schema; exclude sensitive fields
- No rate limiting; all APIs should have rate limits to prevent abuse and brute force
Further Reading
1---2name: api-security-review3description: Review API security including authentication, authorization, rate limiting, input validation, and data exposure.4---56# API Security Review78Review APIs for authentication, authorization, rate limiting, input validation, and data exposure risks.910## Context1112You are a senior security architect reviewing API security for $ARGUMENTS. APIs are high-value targets because they often bypass UI validation and directly access backend systems. Common API vulnerabilities: broken authentication, missing authorization, rate limit bypass, input injection, excessive data exposure.1314## Domain Context1516- **API Authentication**: API keys, OAuth 2.0, JWT, mTLS, basic auth (deprecated)17- **Authorization**: Role-based access control (RBAC), attribute-based access control (ABAC), resource ownership checks18- **Rate Limiting**: Per-user, per-IP, per-endpoint; prevents brute force and DoS19- **Data Exposure**: Over-fetching (returning unnecessary fields), under-fetching (multiple requests), error messages revealing internals20- **API Versioning**: Managing breaking changes, deprecation timelines2122## Instructions23241. **Review Authentication**:25 - **API Keys**: Are keys stored securely? Rotated regularly? Can they be revoked?26 - **OAuth 2.0**: Is the correct flow used? (Authorization Code for web apps, PKCE for mobile, Client Credentials for service-to-service)27 - **JWT**: Signed with strong algorithm (RS256, not HS256 unless symmetric key is secure)? Verified on every request? Expiration enforced?28 - **mTLS**: Certificates exchanged, validated, and rotated regularly?29302. **Review Authorization**:31 - **Resource Ownership**: Can user A access user B's resources? Check at query and database levels32 - **Role-Based Access**: Are roles enforced consistently? Can users elevate their role?33 - **Delegation**: If allowing delegated access (e.g., third-party apps), are permissions scoped? Auditable?34 - **Admin Functions**: Do admin endpoints check admin role? Are admin actions logged?35363. **Check Rate Limiting & Abuse Prevention**:37 - **Rate Limits**: Per-user and per-IP limits? Appropriate thresholds to prevent brute force?38 - **Endpoint Protection**: Are resource-intensive endpoints (search, reporting, export) rate-limited?39 - **Captcha/Challenge**: Is fallback protection in place for high-risk operations (login, password reset)?40 - **IP Blocking**: Is there automated blocking or alerting for suspicious IP activity?41424. **Review Input Validation & Output Encoding**:43 - **Input Validation**: All inputs validated (type, length, format)? Whitelist over blacklist?44 - **Injection Protection**: Protected against SQL injection, command injection, XML injection, path traversal?45 - **Output Encoding**: Responses encoded appropriately (JSON escaping, HTML escaping)?46 - **Error Messages**: Do error messages leak sensitive information (user existence, database structure)?47485. **Assess Data Exposure**:49 - **Over-fetching**: Does API return unnecessary fields? (Passwords, internal IDs, sensitive metadata)50 - **Under-fetching**: Do clients need to make many requests to get needed data? (Indicates missing pagination or query optimization)51 - **Pagination**: Are results paginated? Can attacker retrieve entire database?52 - **Sensitive Data**: Are PII, secrets, payment info properly redacted in responses?5354## Anti-Patterns5556- Using API keys as passwords; **keys should be application-level, not user-level; don't use in user login**57- Trusting OAuth scopes without server-side authorization checks; **always verify permissions server-side**58- Putting secrets in JWT payload (not encrypted); **JWT is signed but not encrypted; don't include secrets**59- Returning all database fields in responses; **explicitly define response schema; exclude sensitive fields**60- No rate limiting; **all APIs should have rate limits to prevent abuse and brute force**6162## Further Reading6364- OWASP API Security Top 10: https://owasp.org/www-project-api-security/65- RFC 6749 (OAuth 2.0 Authorization Framework): https://tools.ietf.org/html/rfc674966- RFC 8949 (JWT, JWS, JWE): https://tools.ietf.org/html/rfc894967- CWE Top 25: Focus on API-relevant vulnerabilities (CWE-89, CWE-79, CWE-200)
sethdford