Troja
All posts
Website-securityMar 22, 2026·16 min read

How to Check If Your Website Is Secure (5-Minute Guide)

A fast, do-it-yourself pass over the security basics every site should get right — TLS, headers, exposed files, and cookie flags — with the exact commands to check each.

By The Troja Team

The five-minute pass

You don't need a pentest to catch the obvious holes. This guide walks the high-signal basics any developer can verify in a few minutes with curl and a browser.

1. HTTPS everywhere (1 minute)

Every page must be served over TLS, and HTTP must redirect to HTTPS.

curl -sI http://yourdomain.com | grep -i "location\|301\|308"

You want a 301/308 redirect to the https:// URL. While you're here, confirm the certificate is valid (browsers will tell you) and not expiring soon.

2. Security headers (1 minute)

Headers are free, high-impact defenses. Check what you're sending:

curl -sI https://yourdomain.com

You're looking for these, at minimum:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: DENY
  • HSTS forces HTTPS and prevents downgrade attacks.
  • CSP is your strongest defense against XSS.
  • nosniff stops MIME-type confusion attacks.
  • X-Frame-Options / frame-ancestors prevents clickjacking.

Missing CSP is the most common — and most damaging — gap.

3. Cookie flags (30 seconds)

Open DevTools → Application → Cookies. Every session/auth cookie should have:

  • HttpOnly — JavaScript can't read it, so XSS can't steal it.
  • Secure — only sent over HTTPS.
  • SameSite=Lax (or Strict) — limits CSRF.

A session cookie without HttpOnly is one XSS away from full account takeover.

4. Exposed files (1 minute)

Misconfigured deploys leave sensitive files in the web root. Probe the usual suspects:

for f in .env .git/config .DS_Store backup.zip config.json wp-config.php; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourdomain.com/$f")
  echo "$code  $f"
done

Anything returning 200 here is a serious leak. A reachable .env or .git/config can hand an attacker your entire codebase and secrets.

5. Directory listing and verbose errors (30 seconds)

  • Visit a folder path like /uploads/. If you see a file listing, directory listing is on — turn it off.
  • Trigger an error (bad input to a form). If you get a full stack trace with file paths, your error handling is leaking internals. Return generic messages; log details server-side.

6. Outdated, vulnerable dependencies (1 minute)

Known CVEs in your dependencies are how a lot of "sophisticated" breaches actually happen.

npm audit --omit=dev

Patch anything high or critical. For non-JS stacks, use the equivalent (pip-audit, bundler-audit, etc.).

7. Authentication basics (30 seconds)

  • Rate-limit login and password-reset endpoints (brute-force protection).
  • Lock out or slow down after repeated failures.
  • Don't reveal whether an email exists ("invalid email or password," not "no such user").
  • Confirm auth/session cookies don't survive logout and expire on idle.

A quick way to test the enumeration oracle: submit a login with a known-bad email and again with a real email plus a wrong password. If the two responses differ in wording, status, or timing, you're leaking which accounts exist.

8. CORS configuration (30 seconds)

A wide-open CORS policy lets any website call your authenticated API from a victim's browser. Check what your API actually allows:

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

If you see Access-Control-Allow-Origin: * (or your API reflecting https://evil.example back) together with Access-Control-Allow-Credentials: true, that's a finding. Allowlist specific trusted origins instead of reflecting whatever asks.

Quick scorecard

CheckPass condition
HTTPSHTTP → HTTPS redirect, valid cert
HSTSheader present, long max-age
CSPheader present, not just unsafe-inline everywhere
CookiesHttpOnly + Secure + SameSite
Exposed files.env, .git return 404
Errorsno stack traces to users
Dependenciesno high/critical CVEs

What this guide doesn't cover

This is the surface. It won't find SQL injection, IDOR/broken access control, business-logic flaws, or BaaS misconfigurations — those need active probing. Treat this as the floor, not the ceiling.

Scan it with Troja

When five minutes isn't enough, Troja runs 120+ checks — headers, TLS, exposed files, SQLi, XSS, access-control flaws, and BaaS misconfigs — against any URL in about 30 seconds, and hands you a prioritized report with fix prompts. Start with a free scan.

Run the scan this post is about.

Free, no signup. See what's hiding inside your walls in ~30 seconds.

Free scan · no signup · results in ~30 seconds
How to Check If Your Website Is Secure (5-Minute Guide) — Troja