TL;DR
These prompts help you secure API endpoints with proper authentication, authorization, rate limiting, input validation, and error handling. They cover common security issues that leave APIs vulnerable to abuse and data breaches.
Complete API Security Audit
Use this prompt to audit and secure all your API endpoints:
Audit all API endpoints in this codebase for security issues.
For each endpoint, check:
- Authentication - Is it required? Is it properly validated?
- Authorization - Does it verify the user can access this resource?
- Input validation - Are all inputs validated and sanitized?
- Rate limiting - Is there protection against abuse?
- Error handling - Do errors leak sensitive information?
- CORS - Is it configured properly?
- Data exposure - Does it return more data than needed?
Create a report with:
- List of all endpoints and their security status
- Critical issues that need immediate fixing
- Recommended improvements
- Code examples for each fix
Prioritize by risk level (critical, high, medium, low).
Add Authentication to Endpoints
Add authentication to my unprotected API endpoints.
Current setup: describe your auth system - JWT, session, API keys
I need:
- Middleware to verify authentication on protected routes
- Proper handling of missing/invalid tokens
- Different protection levels (public, authenticated, admin)
- Rate limiting per user/API key
Endpoints to protect: list endpoints or say "all except /health and /public/*"
Create:
- Authentication middleware
- Route protection wrapper/decorator
- Standard error responses (401, 403)
- Example usage for each protection level
Input Validation
Add comprehensive input validation to my API endpoints.
For each endpoint:
- Define a schema for expected inputs (body, query, params)
- Validate types, required fields, and formats
- Sanitize strings to prevent injection attacks
- Set reasonable limits (max length, array size)
- Return clear validation error messages
Use: Zod / Yup / Joi / class-validator
Also:
- Create reusable validation schemas
- Add validation middleware
- Handle validation errors consistently
- Log validation failures for monitoring
Don't trust any input, even from authenticated users.
Secure Error Handling
Fix error handling in my APIs to not leak sensitive information.
Current issue: Errors may expose stack traces, database queries, or internal paths.
Implement:
- Global error handler that catches all errors
- Different error responses for dev vs production
- Sanitized error messages for clients
- Proper logging of full errors server-side
- Standard error format (code, message, details)
Error types to handle:
- Validation errors (400)
- Authentication errors (401)
- Authorization errors (403)
- Not found (404)
- Rate limit (429)
- Server errors (500)
Never expose: stack traces, SQL queries, file paths, internal IDs in production.
Don't trust the client: Validate everything server-side, even if you validate client-side too. Client-side validation can be bypassed. Server-side validation is your real security.
Authorization Checks
Add proper authorization checks to prevent users from accessing others' data.
Common issues to fix:
- IDOR - User A can access User B's data by changing IDs
- Missing ownership checks on update/delete
- Horizontal privilege escalation
- Vertical privilege escalation (user becoming admin)
For each data-modifying endpoint:
- Verify the authenticated user owns the resource
- Check role/permissions for sensitive operations
- Validate all IDs in the request belong to the user
- Don't rely on hidden fields for authorization
Create reusable authorization helpers:
- canAccess(user, resource)
- isOwner(user, resourceId)
- hasPermission(user, action, resource)
Pro tip: Always verify authorization at the data layer, not just the route layer. Even internal functions should check permissions, in case they're called from unexpected places.
Do I need rate limiting if I have authentication?
Yes. Authenticated users can still abuse your API, either intentionally or due to bugs in their code. Rate limiting protects against both malicious abuse and accidental overuse.
Should I validate data that comes from my own frontend?
Always. Attackers can bypass your frontend and send requests directly to your API. Server-side validation is the only validation that matters for security.
How do I handle sensitive data in API responses?
Only return the data the client needs. Use explicit allow-lists of fields rather than excluding sensitive ones. Consider different response shapes for different user roles.