How to scan your website for vulnerabilities

A launch-readiness scan looks at your app from the outside — the same surface a visitor or an attacker sees — and reports issues that are visible there without breaking into anything. For an AI-built or vibe-coded app, these are exactly the mistakes that tend to ship unnoticed:

• Exposed secrets

  API keys, database service keys, and tokens accidentally bundled into your public frontend.

• Reachable sensitive files

  Things like .env, .git, source maps, or config files left accessible on the public internet.

• Security headers

  Missing or weak browser protections such as HSTS, CSP, and X-Content-Type-Options.

• HTTPS / certificate

  Whether the site is served over HTTPS with a valid certificate and redirects correctly.

• Open endpoints & structure

  Obviously open APIs, risky routes, and robots/sitemap mistakes that invite unwanted access.

GuardMint runs roughly a dozen of these checks against your live URL. The full list is on our methodology page, and you can see the output on a real example report.

You don't need to install tools or run anything locally. A hosted scanner only needs your public URL:

• Make sure your app is deployed and reachable at a public URL (not just running on your laptop).

• Open the scanner and enter that URL.

  With GuardMint, that's /scan — no signup required for your first score.

• Wait for the graded report. The scan fetches your live site and runs its checks in isolation, then returns a score and findings.

• Read the findings by severity and fix the most serious first (see below).

Open-source command-line scanners exist too, but they take setup and security knowledge to run and interpret. A hosted, founder-friendly scan is the fastest way to get a clear, prioritized list before launch.

Findings are ranked by severity for a reason: not everything is equally urgent. Work in this order.

Fix first: exposure

Anything that exposes a secret or private data — a leaked service key, an open database endpoint, a reachable .env. These can be exploited immediately, so treat them as launch-blocking.

Fix next: hardening

Missing security headers, HTTPS hardening like HSTS, and structure issues. They reduce risk and improve resilience but aren't an open door on their own. Our HTTP security headers checklist explains what each one does.

Then: confirm what the scan couldn't

Pair the scan with the manual checks below, and use the full launch security checklist to make sure nothing is missed.

An external scan can't log into your database or read your code, so a few things stay your job. These are the highest-value manual checks:

• Confirm database access rules are scoped per user — see what is Row Level Security and the Supabase RLS checklist.

• Sign in as one user and try to reach another user's data by changing an id; you should be blocked.

• Verify any admin or privileged action is enforced on the server, not just hidden in the UI.

• Double-check no private key is referenced from client-side code or a browser-exposed env variable.

For the database piece specifically, start with what is Row Level Security and the Supabase RLS checklist; for keys, see which environment variables get exposed to the browser.

A scan is the fast, automated first pass — ideal for catching common mistakes before launch. A manual audit or penetration test goes deeper, with a human probing your specific logic, and costs far more. Most founders should scan first and fix the obvious issues, then decide whether the app's risk warrants a deeper review. We walk through that decision in do I need a security audit before launch.

How do I scan my website for vulnerabilities?

Use a hosted scanner that only needs your public URL — no installation required. It fetches your live site the way a browser or attacker would and checks for exposed secrets, reachable sensitive files, missing security headers, HTTPS problems, and obvious misconfigurations, then returns a graded report. With GuardMint you enter your URL at /scan and get a score in a few minutes. Then work through the findings by severity and add the manual checks a scan can't perform, such as confirming your database access rules.

Is scanning my own website legal?

Scanning a site you own or are authorized to test is fine. A launch-readiness scanner like GuardMint only reads what your site already exposes publicly — it doesn't attack, exploit, or break into anything — so it behaves like a normal visitor. You should never run intrusive scans against sites you don't own or have permission to test.

What can't a vulnerability scan find?

An external scan reads only what your live site exposes. It can't see your source code, log into your database, or read your access rules, so it can't prove your data is correctly scoped or your business logic is safe. It also isn't a penetration test. That's why a scan is best paired with manual checks — confirming database rules, testing that one user can't reach another's data, and reviewing auth flows.

How often should I scan my website?

Always scan right before launch, and again after any significant change — a new integration, an auth change, a new deploy, or a domain move. Because secrets and misconfigurations creep in over time, ongoing or scheduled monitoring is the safest approach for a live app rather than a one-time check.