How to know if your site is secure in 5 minutes

You do not need to be a security expert to know whether your site has the most common flaws. With a browser, a terminal and five minutes you can check what an automated attacker tries in the first seconds: whether traffic is encrypted, whether headers are missing, whether there are keys in the code, whether your API accepts requests from anywhere and whether there are files that should not be there. This guide walks you through it step by step, with the exact command, what each result means and what to do depending on what you find. At the end you have how to prioritize and what this test does not detect.

Minute 1: HTTPS and redirect

Type your domain with http:// in front, without the s. It must take you to the https:// version immediately. From the terminal:

curl -sI http://yourdomain.com | head -3
curl -sI http://yourdomain.com/pricing | head -3

Both responses must be a 301 with Location: https://.... If the second one does not redirect, your redirect only covers the home page. Then, with https://, look for the Strict-Transport-Security header: it tells the browser never to use HTTP again. If you are on Vercel, Netlify or Cloudflare, the redirect is already in place and HSTS you have to add yourself. What each certificate detail means, in what your TLS grade really means.

Minute 2: security headers

curl -sI https://yourdomain.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

At least five lines should come out. Each missing one is a protection the browser cannot apply: without X-Frame-Options your site can be embedded in another to trick your users; without X-Content-Type-Options the browser guesses file types; without Content-Security-Policy any injected script runs unchecked. If you do not like the terminal, paste your URL into the headers analyzer. The meaning of each one, in HTTP headers explained for humans.

Minute 3: secrets in the JavaScript

Open your site, right-click, "View page source". Search for .js to see which script files it loads, open the main one and use the browser's find with these terms:

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

From the terminal you can do it in one go over all the home page scripts:

curl -s https://yourdomain.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://yourdomain.com$s";; *) u="https://yourdomain.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Some things are normal to find: the Stripe publishable key (pk_live), the Supabase anon key or the Firebase config are designed to go in the browser. What must never appear: sk_live, service_role, AWS keys (AKIA), OpenAI tokens or anything called secret. If you find one, treat it as compromised and rotate it before removing it from the code. The full list is in secrets your app leaks in the browser.

Minute 4: CORS and cookies

CORS decides which other websites can make requests to your API from the browser. Request one of your endpoints pretending to come from another domain:

curl -sI -H "Origin: https://evil.example" https://yourdomain.com/api/me | grep -i "access-control"

If it answers Access-Control-Allow-Origin: https://evil.example or * together with Access-Control-Allow-Credentials: true, any website can read your users' data with their session. The allowed origin must be yours and yours only. While you are there, look at the cookies in the login response or in the browser's dev tools: session cookies need Secure, HttpOnly and SameSite=Lax or Strict. The detail in misconfigured CORS.

Minute 5: exposed files

Tools and half-finished deployments leave traces. Try these paths and see what code they return:

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://yourdomain.com/$p"
done

What you want to see is 404 (or 301 to your error page). A 200 on .env or .git/config is serious: the first contains your credentials and the second allows downloading the full source code. A 200 on swagger.json or api/debug is not a leak in itself, but it hands an attacker the map of your API.

Bonus minute: what bots see

If you have a minute to spare, look at /robots.txt and /sitemap.xml: that they exist, that they do not block everyone and that the sitemap only has pages you want indexed. It is not security strictly speaking, but a Disallow: / forgotten from testing costs months of rankings.

How to prioritize what you find

Not everything weighs the same. This is the order we use:

• Critical, today. A secret key in the JavaScript; .env or .git accessible; an API accepting any origin with credentials. Rotate, delete, close. Then check whether anyone used it.
• High, this week. No redirect to HTTPS; session cookies without HttpOnly or Secure; debug routes in production.
• Medium, this month. Missing headers; no HSTS; certificate expiring soon without automatic renewal.
• Low. Exposed API documentation, neglected robots.txt and sitemap, headers revealing the server version.

What these five minutes do not detect

Be honest about the limits. This test looks at the surface anyone can see from outside. It does not check whether your database lets users read other users' rows (in Supabase that is RLS, in Firebase the rules), whether your dependencies have known vulnerabilities, whether your business logic allows skipping a payment or whether a form accepts any input. For the first, the Supabase guide and the Firebase one explain how to test it. For the rest you need to look at the code, and the pre-launch checklist collects the essentials.

Scanaris does this and forty more things in 30 seconds

The five steps above are the core of what Scanaris checks, plus about forty tests that do not fit in five minutes: each header separately, secrets with patterns from dozens of services, exposed files with a much longer list, full TLS, cookies, CORS on several routes, and on top of that the state of your SEO and your AI visibility. For every failure it gives you a fix prompt to paste into Lovable, Bolt, Cursor or v0 with the exact change, and it can repeat the scan every day and warn you if anything gets worse. All of it is read-only checks on what is already public on your site.

Frequently asked questions

Is it legal to scan my own site like this?

Yes. Everything here is ordinary requests any browser makes; you are only reading what your server already answers to anyone. Do it only on your own domains or with permission.

What if I cannot use the terminal?

Steps 1, 3 and 5 can be done from the browser (typing URLs and viewing source), step 2 with the free headers analyzer, and step 4 is the only one that needs it. Or let a scanner do it for you.

How often should I repeat it?

Every time you deploy something relevant and, at minimum, once a month. AI-built apps change fast, and a code regeneration can reintroduce a flaw you had already fixed.