We use a 47-point checklist when reviewing AI-built applications, and we're publishing it so builders can run the same first pass themselves.
The checklist covers eight areas that repeatedly produce real findings in the applications we review. It's intended as a practical pre-launch gate, not a theoretical security framework.
Skip an item when it genuinely doesn't apply. When it does apply and you can't confidently answer it, treat that uncertainty as something to investigate before launch.
Category 1: Authentication and session management
- Passwords are hashed using bcrypt, scrypt, or Argon2, never MD5, SHA-1, or plain text
- Authentication tokens have a defined expiration (access tokens: 15–60 minutes; refresh tokens: days to weeks)
- Tokens are stored in HTTP-only, Secure, SameSite cookies, not localStorage or sessionStorage
- A token refresh mechanism exists so users aren't forced to re-authenticate constantly
- Failed login attempts are rate-limited (no more than 5–10 attempts per minute per IP)
- Failed login attempts are logged with timestamp, IP address, and targeted account
- Password reset tokens are cryptographically random, single-use, and expire within 30 minutes
- Session revocation is possible, at minimum "log out everywhere" on password change
- Multi-factor authentication is available for admin accounts (recommended for all users in sensitive applications)
Category 2: Authorization and access control
- Every API endpoint independently verifies the user's identity, with no reliance on frontend route guards
- Every data endpoint verifies the user is authorized to access the specific resource (not just authenticated)
- Resource IDs in URLs and API requests are validated against the requesting user's permissions
- Role-based access control is enforced server-side, not through client-side UI hiding
- Admin endpoints are protected by role verification, not obscurity
- Privilege escalation isn't possible through parameter manipulation (changing role values, user IDs, or permission flags in requests)
Category 3: Input validation and injection prevention
- Every API endpoint validates incoming data against an expected schema (types, lengths, required fields, allowed values)
- Validation happens server-side, with frontend validation treated as UX only
- Database queries use parameterized queries or a properly configured ORM, no string concatenation
- User input rendered in HTML is escaped or sanitized to prevent XSS
- File uploads are restricted by type (whitelist, not blacklist), size, and validated content (not just extension)
- Uploaded files are stored with non-predictable names (UUIDs) and can't be executed by the server
- API request body size limits are enforced
Category 4: Data exposure and privacy
- API responses return only the fields the client needs, with no full database records sent to the frontend for client-side filtering
- Sensitive data (passwords, tokens, SSNs, full credit card numbers) is never included in API responses
- Personally identifiable information is identified and its storage, transmission, and retention are documented
- Data at rest is encrypted for sensitive fields (beyond database-level encryption)
- Data in transit uses TLS: HTTPS is enforced, HTTP requests redirect to HTTPS
- Error responses don't expose internal details (stack traces, database schemas, file paths, library versions)
Category 5: Infrastructure and configuration
- All credentials, API keys, and secrets are stored in environment variables or a secrets manager, never in source code
- The .env file (or equivalent) is in .gitignore and has never been committed to the repository
- Development and production environments are separate: different databases, different API keys, different configurations
- CORS is restricted to specific allowed origins, not Access-Control-Allow-Origin: *
- Security headers are set: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security
- The application runs with minimum necessary permissions: no root/admin execution in production
- Default credentials for databases, admin panels, and third-party services have been changed
Category 6: Error handling and logging
- Unhandled exceptions are caught and return generic error messages to the client
- Detailed error information is logged server-side with timestamps and request context
- Authentication events (login, logout, failed attempts, password changes) are logged
- Data modification events (create, update, delete) are logged with user identity and timestamp
- Logs are stored separately from the application and retained for a defined period
- Logs don't contain sensitive data (passwords, tokens, full credit card numbers)
Category 7: API security
- Rate limiting is applied to all public-facing endpoints, with stricter limits on authentication and expensive operations
- API versioning is implemented to prevent breaking changes for existing consumers
- Request authentication is required for all non-public endpoints
- Pagination is implemented on listing endpoints to prevent full-database dumps
Category 8: Dependency and deployment health
- Dependencies are pinned to specific versions (no ranges or "latest")
- A health check endpoint exists for monitoring services to verify the application is running and connected to its data stores
How to use the checklist
A 'no' in Categories 1 through 4 usually represents a direct security weakness that should be addressed before launch because those categories cover authentication, authorization, input handling and data exposure.
A 'no' in Categories 5 through 8 is more often an operational or maintenance risk. It may not create an immediate breach, but it makes failures more likely and incident response more difficult.
It's common for an AI-built application that hasn't been hardened to produce more 'no' answers than 'yes.' That result is useful because it identifies exactly where the initial feature build stopped short of production engineering.
Use the checklist as a pre-launch gate or as a way to decide whether a deeper review is warranted.