Security checklists, code review perspectives, and policy templates for development teams.
Items to verify before developing a new API endpoint.
Security perspectives to check during API code reviews.
| Check Item | Importance | Explanation |
|---|---|---|
| Authentication middleware is applied to all endpoints | Required | Ensure no authentication checks are missing except for public APIs |
| Object-level authorization checks exist | Required | Verify requested resources belong to the requesting user |
| Admin functions have role verification | Required | Ensure regular users cannot call admin APIs |
| Algorithm is specified during JWT verification | Required | Prevention of alg: none attacks |
| Token expiration is properly configured | Recommended | Access token: within 15 minutes |
| Check Item | Importance | Explanation |
|---|---|---|
| Request body has schema validation | Required | Validation of type, length, and format |
| SQL queries are parameterized | Required | Ensure queries are not built with string concatenation |
| Path parameter format validation exists | Required | Check for expected format such as UUID |
| Pagination parameters have upper limits | Recommended | Prevent excessive requests like limit=999999 |
| File uploads have type and size restrictions | Recommended | Validation of Content-Type and file size |
| Check Item | Importance | Explanation |
|---|---|---|
| Responses do not contain unnecessary fields | Required | Prevent leakage of password_hash, internal IDs, etc. |
| Error responses do not contain stack traces | Required | Do not expose internal information in production |
| Security headers are configured | Recommended | X-Content-Type-Options, HSTS, etc. |
| Content-Type is correctly set | Recommended | Explicitly specify application/json |
| Check Item | Importance | Explanation |
|---|---|---|
| Rate limiting is applied | Required | Especially for authentication and payment endpoints |
| Appropriate logs are being recorded | Recommended | Traceable: who did what and when |
| Secrets are not hardcoded | Required | Use environment variables or secret managers |
| CORS settings are appropriate | Recommended | Avoid using wildcards |
| Dependencies have no known vulnerabilities | Recommended | Check results of npm audit / Snyk |
Templates for basic policies in internal API development. Customize to fit your project.
■ Authentication Methods - User-facing APIs: OAuth 2.0 (Authorization Code + PKCE) - Server-to-server APIs: OAuth 2.0 (Client Credentials) or mTLS - External integration APIs: API Key + HMAC signature ■ Token Management - Access token expiration: 15 minutes - Refresh token expiration: 7 days (rotation required) - Token storage: HttpOnly + Secure + SameSite Cookie ■ Password Policy - Minimum 12 characters, at least one uppercase, lowercase, number, and symbol - Hash with bcrypt (cost factor 12 or higher) - Password list attack protection (Have I Been Pwned API integration)
■ Versioning - Version management via URL path: /api/v1/resources - Minimum 6-month support period for old versions - Notify deprecation via Deprecation header ■ Rate Limiting (Default Values) - General APIs: 100 requests/15 min - Auth APIs: 5 requests/15 min - Public APIs: 30 requests/min - Always return RateLimit-* headers ■ Responses - Content-Type: application/json (fixed) - Error responses in RFC 7807 (Problem Details) format - Never return stack traces in production - Pagination: default 20 items, max 100 items
■ Required Log Fields - Timestamp (ISO 8601, UTC) - Request ID (UUID for traceability) - User ID / API Client ID - HTTP Method + Endpoint - Status Code - Source IP - Response Time ■ Prohibited Log Fields (Sensitive Data) - Passwords / Tokens / API Keys - Credit card numbers - Full PII display (masking required) ■ Monitoring Alerts - Auth failures: Alert at 5+/min - 403 errors: Alert at 10+/min - 500 errors: Immediate alert on 1 occurrence - Rate limit exceeded: Pattern analysis
Detect incidents through monitoring alerts, user reports, or external notifications. Determine severity through initial triage.
0-30 minutesPrevent damage escalation. Invalidate API keys, temporarily suspend affected endpoints, and identify the scope of impact.
30 min - 2 hoursFix vulnerabilities, apply patches, and restore services. Notify affected users.
2-24 hoursConduct postmortem. Perform root cause analysis, develop recurrence prevention measures, and document findings.
1-5 business daysAdditional checklist items for systems integrating AI models and LLM-powered features.
Related: LLM06: Excessive Agency, LLM02: Insecure Output Handling
Related: ASI01: Excessive Agency, ASI03: Insecure Tool/Function Calling, ASI09: Inadequate Sandboxing
Related: LLM03: Training Data Poisoning, ML02: Data Poisoning Attack, ML06: AI Supply Chain Attacks
Security check items specific to code that integrates LLMs, AI agents, and ML models.
| Check Item | Importance | Explanation |
|---|---|---|
| System prompts are not exposed in client-side code or API responses | Required | Prompt leakage enables targeted prompt injection attacks |
| LLM outputs are validated before rendering (HTML/JS/SQL) | Required | LLM-generated content may contain XSS payloads or injection vectors |
| User input and system instructions are clearly separated in prompts | Required | Prevents direct prompt injection by maintaining instruction-data boundary |
| Tool/function call permissions are scoped per user role | Required | Prevent privilege escalation through agent tool access |
| Token count limits are enforced per request and per session | Recommended | Prevents cost explosion and denial-of-wallet attacks |
| RAG retrieval results are sanitized before insertion into prompts | Required | Retrieved documents may contain indirect prompt injection payloads |
| Agent actions and tool calls are logged with full audit trail | Recommended | Essential for incident investigation and compliance in AI systems |
Policy templates for organizations deploying AI models and LLM-powered applications.
■ Model Access Tiers - Tier 1 (Restricted): GPT-4 class / fine-tuned models — requires team lead approval - Tier 2 (Standard): GPT-3.5 class / embeddings — available to all developers - Tier 3 (Open): Open-source models (local inference) — no approval required ■ API Key Management for LLM Providers - One API key per service/environment (never share across projects) - Monthly spend alerts at 50%, 80%, 100% of budget - Hard spending caps enforced at the provider level - Key rotation: every 90 days or immediately upon team member departure ■ Data Sent to External Models - NEVER send: PII, credentials, internal IP, source code, customer data - ALLOWED with review: anonymized logs, public documentation, synthetic data - All prompts to external APIs must be logged (excluding PII)
■ Training Data Requirements - All training data must have documented provenance and licensing - PII must be removed or anonymized before use in training/fine-tuning - Data poisoning checks: validate data integrity with hash verification - Retain training data snapshots for reproducibility and audit ■ RAG (Retrieval-Augmented Generation) Data - Document ingestion pipeline must sanitize content (strip scripts, injections) - Access control on vector store must mirror source document permissions - Embedding models must be versioned and pinned ■ Model Output Data - LLM outputs must not be trusted as authoritative — always verify facts - Generated code must pass the same security review as human-written code - Outputs containing PII must be flagged and redacted before storage
■ Severity Levels for AI-Specific Incidents - P1 (Critical): Prompt injection leading to data exfiltration or unauthorized actions - P1 (Critical): Model serving compromised or returning manipulated outputs - P2 (High): Training data poisoning detected, jailbreak bypass discovered - P2 (High): Agent performing unintended actions outside approved scope - P3 (Medium): Model drift causing degraded accuracy below threshold - P4 (Low): Cost overrun due to excessive token usage ■ Response Procedures - P1: Immediately disable affected model endpoint, notify security team - P2: Quarantine affected model version, roll back to last known good - P3: Trigger retraining pipeline, increase monitoring frequency - P4: Adjust rate limits and budget caps, review usage patterns ■ Post-Incident Requirements - Root cause analysis within 48 hours for P1/P2 - Update prompt injection test suite with new attack vectors - Review and update guardrails configuration
Security-related HTTP status codes used in API design.
| Code | Meaning | Use Case |
|---|---|---|
| 400 | Bad Request | Input validation error |
| 401 | Unauthorized | Authentication required or token is invalid |
| 403 | Forbidden | Authenticated but insufficient permissions |
| 404 | Not Found | Resource does not exist (can also be used instead of 403) |
| 405 | Method Not Allowed | HTTP method not permitted |
| 413 | Payload Too Large | Request body size exceeded |
| 422 | Unprocessable Entity | Syntax is correct but semantics error |
| 429 | Too Many Requests | Rate limit exceeded |
| 500 | Internal Server Error | Internal server error (hide details) |