Website Security: 7 Practical Checks, and What They Don't Prove

HackerMe — Mon, 02 Nov 2026 08:09:59 +0000

Published by the HackerMe team (Agura), the makers of HackerMe, a free automated website security scanner. The checks below are vendor-neutral. Each one is marked as a public check (anyone can run it from outside), a maintainer check (it needs access to the server, the code or the admin panel), or both. Run active tests such as login attempts only on systems you own or have written permission to test.

A clean result on any of these checks does not mean a site is secure. They are a baseline for catching common, avoidable gaps, and each section says what a pass does and doesn't tell you.

1. HTTPS redirect and certificate (public check)

Request the HTTP version and see where it goes, then request the HTTPS version to inspect the response and certificate handling.

curl -sI http://example.com | head -n 5
curl -sS -D - -o /dev/null https://example.com/

Expected: a permanent redirect (301 or 308, see MDN: 308) from HTTP to HTTPS. The second command fails with a TLS error if the certificate is expired, mismatched or untrusted.
Finding: content served over plain HTTP, or a certificate error. A temporary redirect (302/307) is not a vulnerability by itself, treat it as a configuration point to review.
Doesn't prove: that certificate renewal is automated or that every subdomain is covered. Those are maintainer checks.

2. HSTS (public check)

curl -sI https://example.com | grep -i strict-transport-security

Expected: an HSTS policy with a positive max-age appropriate to the site's rollout. One year is a common target for mature deployments, and a shorter value is not necessarily an error (MDN: HSTS).
Careful: includeSubDomains applies the policy to every subdomain, so add it only once all of them serve valid HTTPS. HSTS for the main domain alone does not have that requirement.
Finding: the header is missing on HTTPS responses.
Doesn't prove: that the site has no mixed content.

3. Other security headers (public check)

curl -sI https://example.com

Look for Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and a clickjacking control (X-Frame-Options or CSP frame-ancestors).

Finding: a missing header is a prompt to review. For CSP, unsafe-inline alone is not an automatic failure, because its meaning depends on the full policy and browser support (MDN: script-src).
Doesn't prove: that the application is free of XSS. Headers reduce the impact of a bug, they don't remove it.

4. Exposed files (public check)

Request /.env, /.git/config, /backup.zip and /phpinfo.php on your own domain.

Expected: 404 or 403 with no sensitive content.
Finding: any 200 response that returns real file contents.
Doesn't prove: that nothing else is exposed. This is a short list of well-known paths, not a full discovery.

5. Login and admin surface (public check plus maintainer check)

An accessible login page is not a weakness in itself. Check what sits behind it. Publicly, with a test account on a system you own or are authorized to test, see whether repeated failed logins are throttled. Whether MFA is enforced and how lockouts are configured is a maintainer check.

Finding: administrative functions accessible without proper authentication or authorization, or missing effective protection against repeated login attempts.
Doesn't prove: that credentials are strong or that none have leaked.

6. Cookies and sessions (public check plus maintainer check)

In the browser dev tools, open Application, then Cookies. Session cookies should have Secure, HttpOnly and SameSite.

Logout needs more than deleting the cookie. Using your own test account, verify that a previously valid session token no longer grants access after logout. Maintainer access helps confirm how invalidation is implemented. This follows the approach in the OWASP guide to testing logout and the OWASP Session Management Cheat Sheet.

Finding: missing flags, or an old session token that still works after logout.

7. Software inventory and error handling (maintainer check, partly public)

List your CMS, plugins, frameworks and server packages and compare each with current releases and advisories. Publicly, trigger a 404 and a malformed form input and look for stack traces, file paths or database errors.

Finding: components with known advisories, or detailed errors shown to visitors.
Doesn't prove: that the versions visible from outside are the whole picture, since some are hidden.

Example: reading one result

$ curl -sI https://example.com | grep -i -E "strict-transport|content-security|x-content-type"
strict-transport-security: max-age=31536000
x-content-type-options: nosniff

HSTS and nosniff are present. No CSP header appears in this response. Review whether an appropriate policy is enforced on the site's HTML pages. This output says nothing about whether the application itself has vulnerabilities.

Make it routine

Re-run the baseline after deployments and major updates, and keep a short note of what you checked and when. A passing baseline is a starting point, not a guarantee.

Disclosure: we are the team behind HackerMe, which runs automated checks against a public website for free: https://hackerme.ai. The checklist above works without it.

What would you add to this list? We would like to hear it in the comments.

DEV Community: HackerMe