Blog · Checklist

A Free Website Security Checklist for Anyone Who Built With AI

Five things you can check yourself, right now, in a browser. No code, no terminal, no paid tools. This is the actual checklist, not a preview of one.

Aug 25, 20268 min readTrazo

You don't need to know how to code to run most of this. You need ten minutes, your own site open in a browser, and a willingness to poke at it the way a stranger might. Do these five checks in order — they're roughly worst-risk-first — and you'll know more about your own site's exposure than most people who built one this year.

1. Open your browser's developer tools and look for keys that shouldn't be there

Takes about 2 minutes

Right-click anywhere on your site and choose Inspect, or press F12. Click the Network tab, then reload the page. Click through a few of the requests that load — especially anything with "api" or your database provider's name in it — and look at the request and response details.

You're looking for anything labeled secret, service_role, private, or a long string that looks like a password sitting in plain text where you can see it. A publishable or anon key is normal and fine — those are meant to be public. A secret or service role key is not, and if you can see one from your own browser, so can anyone else.

What you're checking for
  • Any key labeled "secret," "service_role," or "private" visible in Network tab or page source
  • A key that grants full database access sitting in code the browser downloads

2. Try changing a number in your own URL

Takes about 3 minutes

If your site has any page tied to an account, order, or booking — something like yoursite.com/order?id=104 or /account/1057 — log in as yourself, find that URL, and change the number. Try one higher, one lower. If a different customer's name, order, or information loads instead of an error, that's called an IDOR (insecure direct object reference), and it's one of the most common holes in AI-built apps, because it requires the AI to have specifically written a check that most default setups skip.

What you're checking for
  • Changing an ID in the URL shows someone else's data instead of an error or "not authorized" message

3. Log into your database dashboard and look for unrestricted tables

Takes about 3 minutes

If your site runs on Supabase, log in and open the Table Editor. Any table showing an "Unrestricted" badge has no access rules at all — meaning anyone with your project's public URL can read or write to it directly, bypassing your app entirely. Firebase users can check the same thing under Firestore → Rules: if the rules read allow read, write: if true;, that table is open to the internet.

This one is genuinely the biggest single risk on this list, and it's also the fastest to at least see — even if fixing it properly takes more than ten minutes.

What you're checking for
  • Any table marked "Unrestricted" (Supabase) or with rules set to always allow (Firebase)

4. Break a form on purpose and read the error

Takes about 2 minutes

Find a form on your site — contact, login, checkout, anything — and submit something it won't expect: an empty field where one's required, or an obviously wrong value. Look closely at the error message that comes back. A well-built error says something like "Something went wrong, please try again." A leaky one shows a file path, a database table name, a line number, or the words "stack trace." If you can read your own server's internals from the error message, so can anyone testing your form the same way.

What you're checking for
  • Error messages showing file paths, database names, or code details instead of a plain message

5. Check who can actually log in

Takes about 3 minutes

If your site has any kind of login or admin panel, open the user list and read it. This sounds almost too simple to mention, but it's the check people skip most, and it catches two real problems: test accounts from the build process that never got removed, and — less common but worth confirming once — accounts you don't recognize at all. While you're there, actually run the "forgot password" flow once, end to end, so you know it works before the day you need it in a hurry.

What you're checking for
  • Test or placeholder accounts still active from when the site was built
  • Any user account you don't recognize
  • A password reset flow you've confirmed actually sends and works

If you found something

Finding one of these isn't a crisis — catching it before someone else does is the entire point of checking. Most fixes are a short conversation with whatever AI tool built the site: describe what you found, and ask it to fix that specific thing and explain what it changed. Ask it to show you the fix before you trust that it's done, the same way you'd ask a contractor to show you the work before signing off.

If you'd rather not write those follow-up prompts yourself, or you want to go past these five checks into the other two dozen places these problems hide — keys in git history, missing rate limits, session handling, backups nobody's tested — that's exactly what the Security Prompt Pack is built for: the exact wording to paste into your AI tool, ordered worst-first, each with its own ten-second check.

Found something on this list? Fix it right.

The Security Prompt Pack has 32 prompts covering these five checks and 27 more — the exact words to paste into your AI tool, plus a way to verify each fix yourself.

No terminal needed · works with Claude Code, Cursor, Lovable, Bolt, v0, Replit

More from the blog