AI-Built App: Production Security Checklist
Published by Arudra Commercial Services
AI-written code often works but skips security details. Go through every item below before your app goes to production.
AI coding tools can build a working app in days. They are much less reliable at the parts nobody sees in a demo: where the secrets are kept, who is allowed to call each API, and what happens when someone sends a bad request on purpose. Those gaps are what attackers look for.
Sections 1 to 7 and 9 to 10 apply to every web or mobile app. Section 8 applies only if the app also uses an LLM, for example a chatbot.
Check these first
These are the five most common problems in AI-built apps:
Hardcoded secrets
API keys, passwords or database credentials written into the code or the git history.
Missing server-side permission checks
The button is hidden in the UI, but the API behind it is still open to anyone.
No rate limiting
Logins and public endpoints accept unlimited requests.
Fake or outdated packages
Dependencies that don't exist, are impostors, or have known vulnerabilities.
Open CORS
The API accepts requests from any website, sometimes with the user's credentials attached.
1. Secrets & configuration
- No API keys, passwords or database credentials in the source code or git history (scan with gitleaks or trufflehog)
- Secrets live in environment variables or a secrets manager, never in frontend code
- .env files are listed in .gitignore
- Debug mode is off and stack traces are hidden from users
- Default and admin passwords have been changed
2. Authentication & authorization
- Passwords are hashed with bcrypt or argon2, never stored as plain text, MD5 or SHA1
- Login has rate limiting and account lockout
- Sessions and JWTs expire, use a strong signing secret, and are invalidated on logout
- Every API endpoint checks permissions on the server. AI code often hides buttons in the UI but leaves the API open.
- Users can't reach other users' data by changing an ID in the URL (IDOR)
- Admin routes are protected, with 2FA for admins
3. Input & data handling
- All database queries are parameterized or use an ORM, with no SQL built from strings
- All input is validated on the server, not just in the browser
- Output is escaped to prevent XSS (watch innerHTML and dangerouslySetInnerHTML)
- File uploads have type and size limits, are stored outside the web root, and are renamed
- Forms that change data have CSRF protection
- Sensitive data such as phone numbers, payment details and ID numbers is encrypted at rest where needed
4. Dependencies
This is a big risk with AI-written code.
- Every package the AI suggested actually exists and is the real one. AI sometimes invents package names that attackers then register, which is called slopsquatting.
- npm audit, pip-audit, Dependabot or Snyk shows no critical vulnerabilities
- Lockfiles are committed and versions are pinned
- Unused packages are removed
5. Infrastructure & server
- HTTPS everywhere, with HTTP redirected to HTTPS and HSTS enabled
- Security headers are set: CSP, X-Frame-Options, X-Content-Type-Options and Referrer-Policy
- CORS allows only your own domains, never * with credentials
- The firewall allows only the ports you need, and the database is not exposed to the internet
- SSH uses key login only, root login is disabled, and fail2ban is installed
- The OS and runtime get regular updates
- The app runs as a non-root user
6. API protection
- Every public endpoint has rate limiting
- Request body size is limited
- Error messages don't leak internal details such as SQL errors or file paths
- API responses return only the fields needed, never password hashes or internal flags
7. Logging, monitoring & backups
- Logins, failed logins, admin actions and payment events are logged
- Logs never contain passwords, tokens, or full card or ID numbers
- Alerts are set up for errors and unusual traffic (Sentry, Uptime Kuma or similar)
- Backups are automatic, encrypted and stored off the server, and a restore has been tested
8. If the app uses an LLM
- Prompt injection: users can't override the system prompt, and all user and document text is treated as untrusted
- The LLM can't run code or SQL, or delete or send anything, without validation or confirmation
- The LLM API key is only on the backend, never in the app or browser
- Each user has rate limits and token or spend caps, so nobody can drain the API bill
- LLM output is sanitized before it is displayed or used (XSS, links, commands)
- The bot can't reveal other customers' data or its system prompt (test this by trying to trick it)
- Personal data sent to the LLM provider is kept to a minimum and disclosed in the privacy policy
- Conversations are logged for abuse review, with a retention limit
9. Legal & compliance
- A privacy policy and terms of service are published
- In India, follow the DPDP Act 2023: get consent for personal data, collect only what you need, and honour deletion requests
- Payments go through a PCI-compliant gateway such as Razorpay or Stripe, and the app never stores card numbers
10. Before go-live
- Run an automated scan with OWASP ZAP (free) against the staging site
- Manually review the authentication and payment code, or have a security-aware developer do it
- Keep a separate staging environment, and never test on production data
- Write an incident plan: who gets alerted, how to rotate keys, and how to take the site down fast
Need a second pair of eyes?
We build and review web apps, mobile apps and AI-powered business software for businesses in Neyveli, Cuddalore, Chidambaram and across Tamil Nadu. See our website & app development and CRM, ERP & AI software services, or contact us to have your app checked before launch.