Website Security Checklist: HTTPS, Headers, Forms and Dependencies

Check the connection at the address people use

Open the website in a fresh browser window using its public address. Look for certificate errors and unexpected redirects. Try both the main hostname and any supported alternative such as www. A certificate protects transport to the named server; it does not prove that the site's content, forms or business practices are trustworthy.

For your own site, inspect the Network panel for HTTP resources loaded by an HTTPS page. Fix mixed content at its source rather than telling visitors to ignore a warning. Check important pages and download links as well as the homepage. Only test sites and systems you own or are authorized to assess.

Inspect headers without treating them as a scorecard

Use browser developer tools to inspect the main document response. X-Content-Type-Options helps prevent MIME sniffing. Referrer-Policy controls information sent when following links. Frame restrictions reduce unwanted embedding. Content Security Policy can constrain where scripts and other resources load, but needs a policy that fits the application.

OWASP's header guidance explains these protections and their limitations. Do not copy a strict policy without checking sign-in, payments or other required flows. Transport policies such as HSTS also need care: a long-lived setting can make a certificate or subdomain mistake harder to recover from. Test a proposed policy before rolling it out broadly.

Try ordinary form mistakes, then verify the server

On an authorized test environment, submit missing fields, oversized input and an invalid email format. The page should explain the problem without showing a stack trace or database message. Browser validation is useful feedback, not an access control: OWASP recommends validating again on the server because a caller can bypass the page.

Keep authorization separate from validation. A request containing a valid record number must still be checked against the signed-in user's permissions. Add anti-abuse measures appropriate to the operation. A public search and a password-reset endpoint do not need identical controls; both need defined limits and safe failures.

Review dependencies and secrets

Run the package ecosystem's advisory check and inspect the lockfile changes. Prioritize findings by whether affected code is shipped, reachable and used in the vulnerable way. An audit with no findings is not proof of safety, and a development-only advisory is not automatically a public exploit.

Check that private keys, service credentials and internal configuration are absent from public assets and source. For a front-end application, any value bundled into browser JavaScript must be treated as public. If a real secret was exposed, deleting the visible line is not enough: revoke it and investigate where it was used.

Record what you found and what remains

Keep a short checklist with the hostname, date, tested pages, header findings, dependency issues and owner for each fix. Repeat the checks after deployment because hosting and edge configuration can change the result. Review error monitoring to ensure it helps diagnosis without collecting unnecessary form contents.

This checklist is a starting point, not a penetration test. Applications handling accounts, payments or sensitive records need a deeper assessment of authentication, authorization, storage and business logic. Fix material problems before asking visitors to trust those features, then retain a recovery plan for the next incident.

Assign each unresolved issue to someone who can change the relevant system, rather than leaving a generic warning on a checklist.