How to check if your website is secure (without being a developer)

"Is my website secure?" doesn't have a yes-or-no answer. Nobody can promise a site is perfectly safe, including me, and you should be wary of anyone who does. What you can do is check for the problems that actually hurt small sites and new apps, and fix the ones you find.

This is the list I'd go through. It's written for people who built a site with a tool like Lovable, Bolt, Base44, Replit, or v0, but most of it applies to any website. You don't need to read code.

1. HTTPS works, everywhere

Open your site and look at the address bar. You want https:// and no "Not secure" warning. Then check two more things:

• Type your address with http:// instead. It should jump to https:// on its own.
• If you have a www version and a version without it, both should end up at the same HTTPS address.

Most hosts handle this for you, but custom domains sometimes get missed. Also note when your certificate expires (click the padlock or site settings icon in your browser). Most hosts renew it automatically. It's worth knowing yours does.

2. No secret keys in your page

This is the problem I see most often in apps built with AI tools. A secret key, like an OpenAI key or a Stripe secret key, ends up in the JavaScript that every visitor downloads. Anyone who finds it can use it, on your bill.

To look for yourself:

1. Open your site in Chrome, right-click, and choose Inspect.
2. Go to the Sources tab and press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search all files.
3. Search for sk-, sk_live_, service_role, and secret.

Some keys are meant to be public, like a Supabase anon key or a Firebase config. How to hide API keys in a React app explains which are which, and what to do if you find a real one.

3. Your database is locked

If your app saves anything (accounts, orders, messages), the database rules decide who can read it. This matters more than anything else on this list, because it's where your users' information lives.

• Supabase: every table should have row level security on. A red "Unrestricted" label in the Table Editor means it's off. See Supabase row level security for beginners.
• Firebase: your rules shouldn't allow reads or writes for everyone, and test mode rules should be gone. See Firebase security rules for beginners.
• Base44 and other all-in-one builders: check each table's permissions in the builder's dashboard. See the Base44 checklist.

4. One user can't see another user's stuff

You can test this yourself, and it catches problems no automated tool reliably finds:

1. Sign up for your own app with one email.
2. Open a private window and sign up with a second email.
3. As the second person, try to view the first person's profile, orders, or messages. Try changing any number or ID in the address bar.
4. Log out completely and try to open pages that should need a login.

If you can see something you shouldn't, describe exactly what you did to your builder and ask it to check access on the server.

5. Security headers are set

Security headers are short instructions your site sends to the browser, like "don't let other sites put me in a frame" and "only use HTTPS from now on." They block whole categories of attacks for free. When I checked 76 live vibe-coded apps, 97% were missing them.

You can see yours in the browser's developer tools: open the Network tab, reload, click the first request, and look under Response Headers for content-security-policy and strict-transport-security. The fix is in How to add security headers.

6. Paid features can't be abused

If your app calls an AI model, sends email, or sends texts, each use costs you money. Ask:

• Does a stranger need to be logged in to trigger it?
• Is there a limit on how many times one person can use it per minute?
• Is there a spending cap in the provider's dashboard?

The third one is the easiest and takes two minutes. Do it today even if you skip the rest.

7. Google doesn't flag your site

Google keeps a public list of sites it considers unsafe. Paste your address into the Google Safe Browsing site status tool. A new site should come back clean. If it doesn't, Google explains why.

8. Your software is up to date

If your site runs on WordPress or a similar system, outdated plugins are one of the most common ways sites get hacked. Update them, and remove ones you don't use. If you built with an AI tool, ask it to check your project's packages for known security issues, or use your builder's own scan if it has one. Lovable, Bolt, Replit, and Base44 all have one.

What an outside check can and can't tell you

Every check above, except your builder's own scan, looks at your site from the outside, the way a stranger would. That's useful, because it's what an attacker sees too. But it can't see your server code or your database settings directly, so a clean result means "nothing obvious from the outside," not "perfectly safe." Re-check after big changes.

The short version

• HTTPS on every version of your address.
• No secret keys in the page's JavaScript.
• Database rules on, tested with a second account.
• Security headers set, and paid features have limits.
• Google Safe Browsing shows nothing, and your software is current.

The free Throttle Bird scan runs the outside checks for you in under a minute: HTTPS and certificate, exposed secret keys in your page and its JavaScript, security headers, link previews and search basics, and, if your app uses Supabase or Firebase and you prove you own it, whether a stranger can read your data. It only reads, it never submits forms, and it explains everything in plain English.

Sources: MDN: Web security practical guides, Google Transparency Report: Safe Browsing, OWASP Top 10.