Built a site with AI? Run this before you publish

Act as a senior application security engineer.

Run a security audit of this application before it goes to production.

IMPORTANT:
- Don't assume the application is secure just because it works.
- Don't give only generic security advice.
- Actually inspect the code, configuration, database rules, authentication flows, API routes, storage setup, use of environment variables, dependencies and deployment configuration.
- Don't make destructive changes or touch production systems without my explicit approval.
- Never show or expose real secrets in your answer.

Base your audit on the OWASP Top 10, the OWASP API Security guide and the security best practices of each platform in use.

AUDIT THE FOLLOWING:

1. SECRETS AND API KEYS
- Search the whole repository and the Git history for API keys, tokens, passwords, private keys, database URLs, service role keys and other secrets.
- Check the .env files and confirm sensitive .env files are ignored by Git.
- Identify secrets that were exposed on the client side by mistake.
- Tell apart public keys that are safe for the client from privileged secrets that must stay on the server.
- If any secret was already committed, warn me that deleting the file is not enough and recommend rotating or revoking the key.

2. AUTHENTICATION
- Review sign-up, login, logout, password recovery, OAuth, sessions, cookies, JWT usage and token storage.
- Check that authentication is actually enforced on the server.
- Look for account enumeration, weak password recovery, insecure sessions and ways to bypass authentication.
- Check brute force protection and rate limiting where it makes sense.

3. AUTHORIZATION
- Don't assume being logged in means having permission.
- Inspect every sensitive API route and server action.
- Verify on the server who owns each resource and what permissions they have.
- Test whether User A can read, change, delete, download or update User B's resources just by changing an ID.
- Separately check the functions only admins can use.
- Look specifically for IDOR/BOLA and broken function-level authorization.

4. DATABASE SECURITY
- Review database permissions.
- If it uses Supabase, inspect the Row Level Security policies of every exposed table, view and function, and confirm privileged or service role keys never reach the client.
- If it uses Firebase, inspect the Security Rules for Firestore, Realtime Database and Storage, and look for read or write access that is too broad.
- Verify data isolation between users and between customers.

5. API SECURITY
- List every API route, server action, webhook, RPC function and endpoint.
- Check authentication and authorization on every sensitive endpoint.
- Validate on the server every parameter that comes from outside.
- Check usage limits on authentication, expensive endpoints, uploads, messages, AI calls, payment actions and other operations that can be abused.
- Look for SSRF and insecure use of third-party APIs where relevant.

6. INPUT AND INJECTION
- Look for SQL and NoSQL injection.
- Look for XSS, command injection, template injection, path traversal and unsafe dynamic queries where applicable.
- Prefer parameterized queries.
- Validate inputs on the server.
- Encode or sanitize user-controlled content according to where it is displayed.

7. FILE UPLOADS AND STORAGE
- Review the upload endpoints.
- Limit the accepted file size and types.
- Don't trust only the file name or the type reported by the browser.
- Generate safe names to store files.
- Prevent path traversal and unauthorized file access.
- Review bucket and storage permissions.

8. FRONTEND TRUST BOUNDARIES
- Treat everything that runs in the browser as controlled by an attacker.
- Find security decisions that live only in frontend code.
- Re-check sensitive permission checks on the server or in the database.
- Confirm no privileged credential was bundled into the frontend JavaScript.

9. ADMIN ROUTES
- Find admin panels, admin APIs, moderation tools, internal endpoints and privileged actions.
- Verify role and permission checks on the server.
- Try to identify ways a regular logged-in user could trigger these functions.

10. SECURITY CONFIGURATION
- Check the CORS configuration.
- Review the relevant security headers.
- Check cookie flags where applicable.
- Make sure debug mode is off in production.
- Prevent stack traces, internal paths, database errors, secrets and implementation details from reaching users.

11. DEPENDENCIES AND SUPPLY CHAIN
- Inspect dependencies for known vulnerabilities and unnecessary packages.
- Review the lockfiles.
- Flag security-sensitive packages that are outdated or risky.
- Check CI/CD workflows for insecure use of secrets or untrusted inputs.

12. LOGGING AND MONITORING
- Confirm failed login attempts and important security events can be monitored.
- Make sure sensitive information, passwords, access tokens, authorization headers and unnecessary personal data don't go into the logs.
- Recommend security alerts for suspicious behavior where it makes sense.

13. PRODUCTION CONFIGURATION
- Look for development settings turned on in production by mistake.
- Review the separation between environments.
- Check database and storage exposure.
- Review deployment-specific configuration files.

14. ATTACKER TEST
Assume you are:
A) someone who is not logged in,
B) a regular logged-in user,
C) a malicious user trying to access someone else's data.

For each role, say which sensitive actions you would try and whether the current implementation blocks each of them.

RESPONSE FORMAT:

Start with:

SECURITY AUDIT SUMMARY
Critical:
High:
Medium:
Low:

Then, for each issue found, include:

Issue:
Severity:
Location/File:
Evidence:
Why it matters:
How it could be exploited:
Recommended fix:
Verification test:

Don't say something is vulnerable without evidence in the code or configuration. If you're not sure, clearly mark it as needing manual verification.

After the issues, include:

PRE-LAUNCH SECURITY CHECKLIST

Use:
[OK]
[FAILED]
[NEEDS MANUAL REVIEW]

Finally, include:

THE 5 THINGS I NEED TO FIX BEFORE PUBLISHING

Prioritize exploitable issues involving:
- exposed secrets
- broken authentication
- broken authorization
- access to other users' data
- exposed database or storage
- admin access
- injection
- expensive operations without limits

Don't mark the application as "secure" just because you didn't find obvious issues. Explain what still needs manual penetration testing or verification in production.