The 20 security checks I ran on my AI-built SaaS products

I found this list of 20 things to check before calling a SaaS product protected. So I gave it to the AI tools helping me build LinesFly and HuddlePops and asked them to go through every item.

Not skim the list. Not tell me the app “looks secure.” Check the code, show me evidence, fix what was missing, and then go back and verify the work.

I want to be careful with the wording here. I checked all 20 areas across both products. That does not mean every item needed the same fix. Some controls were already there. Some needed work. Some did not apply because that part of the product does not exist or another service handles it.

The point was to make the AI prove the answer instead of giving me a confident green check.

Some protection is better than no protection

I know a real software engineer or security professional can probably add another 20 things to this list before lunch. That does not make these 20 useless.

I think this is where people building with AI can get stuck. We know we do not know everything, so the temptation is to avoid the subject or assume the AI already handled it.

I did not want to do either one.

LinesFly and HuddlePops are working products. They have accounts, databases, forms, APIs, and information people expect me to protect. I may not write the code myself, but I still own the responsibility for what the product does.

What the 20 checks are actually checking

The original list is short. That makes it easy to save and easy to misunderstand. Here is what I asked the AI to look for behind each line.

1. Hide API keysKeep private credentials on the server and out of browser code.
2. Purge Git secretsCheck the project history, not just the files you can see today.
3. Use a public database keyIf the database has a client-safe key, use only that in the browser and keep privileged keys on the server.
4. Enable row-level securityWhen the database supports it, restrict which rows each user can read or change.
5. Encrypt sensitive dataProtect sensitive information while it moves and, where needed, while it is stored.
6. Enforce server-side authenticationA hidden button is not security. The server has to verify access.
7. Lock record accessA signed-in user should only reach the records they are allowed to use.
8. Block field tamperingDo not trust a browser to decide roles, prices, ownership, or other protected values.
9. Secure session cookiesUse secure, HTTP-only cookies with sensible expiration and same-site rules.
10. Hash passwordsNever store readable passwords. If a managed authentication service handles this, verify that it owns the job.
11. Rate limit loginSlow down repeated attempts instead of giving an attacker unlimited guesses.
12. Add bot protectionProtect public forms and endpoints from automated abuse.
13. Parameterize queriesKeep user input separate from database instructions.
14. Validate all inputCheck type, length, format, and allowed values again on the server.
15. Escape user contentDo not let content submitted by a user become executable page code.
16. Restrict file uploadsLimit file type and size, rename uploads safely, and store them away from executable code.
17. Trim API responsesReturn only what the screen needs, not entire database records.
18. Add security headersTell browsers how tightly they should handle scripts, framing, content types, and connections.
19. Force HTTPSKeep traffic encrypted and redirect insecure requests.
20. Scan dependenciesCheck the packages your app depends on and deal with known vulnerabilities.

A few of these depend entirely on the product. If your app does not accept file uploads, restricting file uploads is not a feature you need to invent. If a managed authentication service handles passwords, your application should not start hashing another copy. If your database does not offer row-level security, record access still needs to be enforced somewhere else.

“Not applicable” can be a valid answer. It just needs a reason.

What this list does not prove

It does not prove that LinesFly or HuddlePops can never be hacked. No serious person should promise that.

It does not prove the AI noticed every problem. It can misunderstand the architecture, miss a route, trust a test that does not test enough, or protect the code while missing something in the live configuration.

It also does not replace the security work that continues after launch. Dependencies change. Features get added. A safe upload flow can become unsafe six months later when somebody adds a new file type. Security is not a box I checked once and finished.

For a more complete standard, the OWASP Application Security Verification Standard provides a much deeper set of requirements for verifying web application security controls. My 20-item list is not trying to compete with that.

Then everybody in the comments said: do a penetration test

I have not done that yet.

A penetration test is different from asking the AI that helped build the product to review its own work. A tester approaches the deployed product like somebody trying to find a way through it. That outside point of view matters, especially because the AI can repeat the same assumption it made when it wrote the code.

The OWASP Web Security Testing Guide lays out a much broader framework for testing web applications and reporting what was found. It also makes an important point: automated tools provide breadth, but deeper problems often require application context and human judgment.

People recommended hiring somebody who specializes in penetration testing. I think that is the safer answer when a product handles sensitive information, payments, high-value accounts, or anything where a mistake can seriously hurt somebody.

If your budget is tight, AI can still help you do a defensive review and prepare for that next step. I would not call that the same thing as an independent professional penetration test. I would call it more protection than you had yesterday.

The security prompt you can copy

This is the prompt I would use with Claude Code or Codex. It tells the AI to inspect first, show its evidence, fix what it safely can, and then repeat the audit after the fixes.

It also gives the AI boundaries. That matters. You should only test software and environments you own or have explicit permission to test.

Act as a defensive application security engineer working only on this software project and on environments I explicitly own or control.

Your job is to inspect this existing codebase before changing anything, audit its security, fix safe in-scope problems, and verify your work. Do not change the product's design or intended functionality.

Safety boundaries:
- Do not attack, scan, or test third-party systems.
- Do not run destructive tests, delete data, exfiltrate information, expose secrets, or use real customer data.
- Do not rotate credentials, change DNS, alter payment settings, modify production access, or perform active penetration testing without my explicit approval.
- Do not rewrite Git history or remove historical commits without my explicit approval.
- Redact secret values from every response and report.

First inspect and document:
- the tech stack, deployment platform, database, authentication, APIs, file uploads, third-party services, and current security controls;
- how secrets and environment variables are stored;
- which parts run in the browser and which run on the server;
- any existing security tests, headers, logging, rate limits, bot protection, dependency scanning, and privacy controls.

Audit these 20 areas:
1. Hide API keys
2. Purge Git secrets
3. Use only client-safe/public database keys in the browser
4. Enable row-level security where supported and appropriate
5. Encrypt sensitive data in transit and at rest where required
6. Enforce server-side authentication
7. Lock record access and verify authorization on every protected operation
8. Block protected-field tampering
9. Secure session cookies
10. Hash passwords with an appropriate modern password-hashing method, or verify the managed auth provider does it
11. Rate limit login and other sensitive endpoints
12. Add bot and abuse protection to public endpoints
13. Parameterize database queries
14. Validate all input on the server
15. Escape or safely render user content
16. Restrict file uploads
17. Trim API responses to the minimum required fields
18. Add appropriate security headers, including a practical Content Security Policy
19. Force HTTPS
20. Scan production and development dependencies

For each item, report one status: Complete, Partial, Missing, Not applicable, or Needs my input. Include the evidence you inspected, the risk, and the recommended action. Do not mark anything Complete without evidence. If an item is Not applicable, explain why and identify the control that handles the underlying risk instead.

Then:
1. Fix every safe issue you can fix inside this repository without changing intended functionality.
2. Preserve existing architecture and reuse existing security tools and patterns.
3. Create proper migrations if the database schema must change.
4. Add or update tests for the security behavior you changed.
5. Run the build, tests, dependency audit, and any safe static checks available.
6. Review the final diff for accidental secret exposure, excessive API fields, disabled protections, or unrelated changes.
7. Repeat the full 20-item audit after the fixes. This is the verification pass. Do not rely only on the first report or on tests you wrote yourself.

Finish with a concise final report containing:
- what was already protected;
- what you fixed;
- what was not applicable;
- what still needs my input;
- what you could not verify;
- any remaining high, medium, or low risks;
- whether an independent professional penetration test is recommended and why.

Do not claim the product is completely secure. Be specific about what was and was not tested.

Do not accept “everything looks good”

The report is part of the work.

I want each check labeled clearly: Complete, Partial, Missing, Not applicable, or Needs my input. I want the file, route, configuration, test, or live behavior that supports the answer. I want to know what changed and what the AI could not verify.

Then I want the second pass.

That last part comes from experience. I have already watched an AI tell me that every automated test passed while the actual product was broken. Security is not the place where I want to take the first green light personally.

Ask it to audit the final state again. Ask it to review the diff. Ask it to make sure it did not expose a secret while trying to hide one. Ask it to tell you what still needs a human.

A few quick questions