How to check if a website is secure: a 10-minute external checklist.

Ten checks you can run from a browser and a terminal to tell whether a website is secure: TLS, security headers, exposed files, admin paths, cookies, third-party scripts, source maps, and subdomains.

To check if a website is secure from the outside, verify that it enforces HTTPS with a valid certificate, sends the standard security headers, does not expose configuration files, backups, or directory listings, keeps admin interfaces behind authentication, sets secure cookie flags, loads third-party scripts only from sources it trusts, does not publish source maps or secrets in its JavaScript, and has no forgotten subdomains. Each of those is a two-minute check, and this guide walks through all ten with the exact command and what a bad result looks like.

Everything here is read-only and sends ordinary requests any browser would send. Even so, only run it against sites you own or have written permission to test.

1. Is HTTPS enforced with a valid certificate?

curl -sI http://example.com | grep -i -E "^HTTP|^location"
curl -sI https://example.com | head -1

The HTTP request should answer with a 301 or 308 redirect to the HTTPS URL. The HTTPS request should return a 200 without certificate warnings. A browser warning, an expired certificate, or an HTTP page that loads without redirecting all fail this check.

2. Are the security headers present?

curl -sI https://example.com | grep -i -E "strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy"

You want to see Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options or a frame-ancestors directive, Referrer-Policy, and Permissions-Policy. Missing HSTS and CSP are the most common findings on otherwise well-run sites. Each header and its recommended value is covered in HTTP security headers explained.

3. Are configuration files or backups exposed?

for p in .env .git/HEAD .git/config backup.zip db.sql config.php.bak .DS_Store; do
  printf "%-18s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/$p"
done

Every line should be 404 or 403. A 200 on .env or .git/HEAD is a critical exposure: it usually means the whole repository or every secret the application uses is downloadable. Be careful with single-page applications that return 200 for every path; confirm by checking that the body is actually the file and not the app shell. We cover the mechanics of these leaks in Exposed .env files, source maps, and API keys.

4. Is directory listing enabled?

curl -s https://example.com/static/ | grep -i "index of"
curl -s https://example.com/uploads/ | grep -i "index of"

Any "Index of /" page means the web server is listing directory contents. Uploads, static, assets, backups, and images directories are the usual offenders. The fix is one line in the server configuration.

5. Are admin interfaces reachable?

for p in admin wp-admin administrator phpmyadmin _internal ops console grafana; do
  printf "%-16s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/$p"
done

A login page at an admin path is normal and Low severity. An admin interface that renders content without asking for credentials is Critical. Note also any admin tool on a separate subdomain, which the subdomain check below will surface.

6. Do cookies have secure flags?

curl -sI https://example.com | grep -i "set-cookie"

Session cookies should carry Secure, HttpOnly, and SameSite=Lax or Strict. A session cookie without HttpOnly can be stolen by any script injection; without Secure it can be sent over plain HTTP. Log in and check the authenticated cookies too, since those are the ones that matter.

7. Which third-party scripts are loaded?

Open the browser developer tools, load the page with the Network tab open, and filter by JS. Every script from a domain you do not control runs with full access to the page, including form fields and cookies that are not HttpOnly. Analytics and tag managers are expected; an unknown domain is worth investigating. For sites subject to GDPR or DPDP, note which third-party requests fire before any consent is given.

8. Are source maps or secrets published in the JavaScript?

curl -s https://example.com/ | grep -o -E "src=\"[^\"]+\.js\"" | head
# then for a bundle URL:
curl -s https://example.com/static/js/main.abc123.js | tail -c 200
curl -s https://example.com/static/js/main.abc123.js | grep -o -E "(AKIA[0-9A-Z]{16}|sk-[A-Za-z0-9]{20,}|AIza[0-9A-Za-z_-]{35})"

A sourceMappingURL comment at the end of a production bundle means the original source is published. Any match on the key patterns means a credential is in the client. Treat a live key as an incident: rotate it before doing anything else.

9. What subdomains exist?

curl -s "https://crt.sh/?q=%25.example.com&output=json" | grep -o -E "\"name_value\":\"[^\"]+\"" | sort -u | head -50

Certificate transparency logs list every hostname that has ever had a certificate issued. Look for staging, dev, test, old, api-v1, and anything you do not recognise. Then repeat checks 1 through 8 on each one that still resolves. Forgotten subdomains are the single most common source of serious findings on mature sites.

10. Does the site expose a security contact?

curl -s https://example.com/.well-known/security.txt

A security.txt file (RFC 9116) tells researchers how to report a vulnerability. Its absence is not a vulnerability, but its presence is a good signal that someone is responsible for security and will act on a report.

What does a good result look like?

What can this checklist not tell you?

It cannot find logic flaws, authorisation bugs behind a login, injection vulnerabilities that need crafted input, weaknesses in the AI features, or anything on the internal network. A clean result means the common exposures are absent today. It does not mean the site is secure, and the surface changes every time someone deploys.