SaaS Security Checklist:5 Checks That Prevent Disasters
The SaaS security checklist for non-technical founders: 5 checks that prevent 99% of security disasters, plus a copy-paste audit prompt that runs them all.
A SaaS security checklist of five checks prevents 99% of SaaS security disasters: data isolation, secure passwords, input validation, permission enforcement, and input sanitisation. You don't need to become a security expert to run them. You need to know the five checks exist, ask your AI assistant whether each one is implemented, and demand fixes where it isn't. This is the full checklist — the test for each check, the fix, and the copy-paste prompt that audits all five in one go.
Here's the truth nobody selling you "AI builds your app in a weekend" mentions: AI will happily build you an insecure app if you never ask for security. These five checks are what separate amateur apps from professional ones — and one security hole can destroy your business before it starts.
The 5-check SaaS security checklist
| # | Check | The question to ask | Passing answer |
|---|---|---|---|
| 1 | Data isolation | Can users see each other's data? | No — the database blocks it, even if the code has bugs |
| 2 | Passwords | How are passwords stored? | Handled by Supabase Auth, or hashed irreversibly |
| 3 | Input validation | Can bad data get in? | No — required fields, lengths, formats and ranges are all checked |
| 4 | Permissions | Can users do things they shouldn't? | No — permissions are checked before every action |
| 5 | XSS prevention | Is user input safe to display? | Yes — anything a user types is sanitised before it's shown |
Every check follows the same pattern: run the test, and if it fails, paste the fix prompt into your AI tool. Let's walk through them.
Check 1: Can users see each other's data?
The test is brutally simple. Log in as Customer A, change the URL or click around, and see if you can reach Customer B's data. If you can, you have a massive problem — the kind that turns into a GDPR violation, then a lawsuit, then a dead business.
The fix is Row-Level Security: rules that live in the database itself, so that even if there's a bug in your code, the database blocks the access. Tell your AI: "Add Row-Level Security so users can only see their own organization's data." Think of it as putting a lock on every apartment door instead of trusting nobody will walk into the wrong flat. This check deserves its own article, and it has one — Row-Level Security explained for non-technical founders covers it properly.
Check 2: Are your passwords actually secure?
Ask your AI: "How are passwords stored in the database?" There are two bad answers. "Plain text" is a disaster — never acceptable. "Encrypted" sounds safe but isn't, because encryption is reversible. The good answers are "hashed with bcrypt or scrypt" (irreversible) or, best of all, "handled by Supabase Auth."
The real fix here is a decision, not code: don't build your own password system. Supabase Auth handles password hashing, password reset, email verification, session management, and multi-factor authentication — problems that professional security teams have already solved. Building your own version is like writing all your passwords on paper by the front door instead of installing a proper security system. If passwords leak, every account is compromised and users never trust you again.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →Checks 3 and 4: bad data and broken permissions
Check 3 — can bad data get in? Try to create a record with empty required fields, a 10,000-character name, an invalid email format, or a negative number where only positive makes sense. If your app accepts it, you have no validation — and bad data breaks features in weird ways your users will find before you do. The fix prompt: "Add validation that checks required fields are filled, text fields have maximum lengths, emails are valid format, numbers are in acceptable ranges, and dates are valid."
Check 4 — can users do things they shouldn't? Log in as a regular user, not an admin, and try to delete other users, change subscription settings, or access admin pages. If you can, your permission system is broken — the digital equivalent of giving every resident a master key to all the apartments. The fix prompt: "Add permission checks: regular users can only edit their own stuff, only admins can delete users, only owners can change the subscription — and check permissions before allowing actions." Without this, a regular user deletes everything, and you spend the week issuing refunds to angry customers.
Check 5: Is user input safe to display?
This one is the sneakiest. Ask your AI: "If a user enters HTML or JavaScript in a text field, will it execute on other users' screens?" If yes, you have an XSS vulnerability — your users can hack each other. User A puts a script in their profile name; User B opens that profile; malicious code runs on User B's screen and steals their data. Legal liability, destroyed reputation.
The fix prompt: "Sanitise all user input before displaying it. Remove any HTML, JavaScript, or dangerous code." Building rules for what's allowed on the door — nothing explosive.
The 5-minute security audit
You don't have to run the checks one by one. Paste this into your AI tool and let it do the work:
Audit this app for security issues:
1. Can users see other organizations' data? (Check Row-Level Security)
2. How are passwords stored? (Should use Supabase Auth)
3. Is user input validated? (Check for required fields, length limits, format validation)
4. Are permissions enforced? (Can regular users do admin actions?)
5. Is user input sanitised before display? (Check for XSS prevention)
For each issue found, explain the risk and how to fix it.
It will tell you what's wrong. Fix what's broken, starting with anything touching data isolation.
Better still, bake security into how you ask for features in the first place. "Build me a contact management app" gets you something that works but is insecure. "Build me a contact management app with Row-Level Security, Supabase Auth for passwords, input validation, permission checks, and sanitised user input" gets you secure by default. Security is one of five dimensions worth auditing before launch — the full code quality audit scores all of them.
Run the audit. Fix what's broken. Sleep peacefully. Build it secure from day one — because retrofitting security after a breach is a job you never want.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →Frequently asked questions
Do I need to be a security expert to launch a SaaS?
No. You need three things: know these 5 checks exist, ask your AI assistant whether each one is implemented, and demand fixes where they're missing. The checks cover the failures that prevent 99% of disasters — data isolation, passwords, validation, permissions, and XSS.
Which security check matters most?
Data isolation. If Customer A can see Customer B's data, you're looking at a GDPR violation and a lawsuit — the failure mode that destroys businesses outright. Row-Level Security fixes it at the database level, so even buggy code can't leak data across customers.
Should I build my own login and password system?
No. Use Supabase Auth. It handles password hashing, resets, email verification, session management, and multi-factor authentication — all the places where home-made auth goes wrong. Custom password storage is how "plain text passwords" ends up in a headline with your product's name in it.
When should I run the security audit?
Before your first real user touches the app, and again whenever you add a feature that stores or displays user data. The audit takes five minutes with the copy-paste prompt above — there is no version of your roadmap where skipping it is the smart trade.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.