Website Security Checklist for Small Teams (2026)

A website security checklist should help a small team make decisions, not collect impressive-looking grades. This website security audit covers fifteen things you can inspect in an evening, with a concrete next action for each. Start with your production domain, its important subdomains, and the people who control deployment. Work only on systems you own or are authorized to review.

You will need browser developer tools, access to your hosting and DNS dashboards, and a terminal with curl. Use a staging environment for changes that affect login, checkout, or browser policies. An external check is a useful starting point; it cannot establish that your application’s authorization or business logic is correct.

How to check website security without losing the evening

Create a short record before changing anything:

Asset: app.example.com
Check: session cookie flags
Evidence: browser response headers, checked today
Owner: application team
Next action: verify Secure and HttpOnly on production session
Retest: sign in, sign out, password reset

Keep evidence small and redact credentials. A useful finding includes the affected host, the observed behavior, an owner, and a retest. Treat “could not check” as a separate outcome from “passed.”

1. Confirm HTTPS and the redirect path

Open both HTTP and HTTPS versions of your own site. Look for a valid certificate and a predictable redirect to the intended canonical host. Check the public application, not only the marketing homepage.

curl -sS -o /dev/null -D - http://example.com/
curl -sS -o /dev/null -D - https://example.com/

Fix certificate or redirect failures before tightening browser policies. A redirect loop through a CDN and origin deserves its own ticket.

2. Introduce HSTS deliberately

Inspect Strict-Transport-Security on the HTTPS response. Begin with a short duration while testing renewal and redirects. Increase it after the deployment is reliable. Add includeSubDomains only when every affected subdomain supports HTTPS; preload is a separate commitment, not a box to tick for a better score. The HSTS specification defines the policy and its scope.

3. Inspect security headers on real pages

Check the login page, an application page, a missing route, and an error response. Review X-Content-Type-Options, Referrer-Policy, framing controls, and relevant Permissions-Policy directives. Confirm that the CDN has not replaced the origin’s intended values. A homepage-only check can miss a separate application deployment.

4. Plan Content Security Policy around your application

Inventory scripts, styles, images, frames, and outbound browser connections. Start a candidate CSP in report-only mode and exercise normal journeys. Investigate violations before enforcement. A restrictive policy that prevents customers from completing checkout is an incomplete rollout, not a successful security improvement.

5. Check for exposed configuration files

Inspect your deployment artifact and document root for .env, Git metadata, diagnostics, and backup files. On your own host, a small targeted request can verify whether a known unwanted path is reachable. Do not assume HTTP 200 proves exposure: an SPA may return its homepage for every path. Validate the response content without copying secrets into shared logs.

6. Keep backups outside the web root

Look for deployment archives, database dumps, and old release folders in publicly served directories. Move them to private storage and restrict access to the people and automation that need them. The test is simple: a backup should be available through your authenticated restore process, not through a website URL.

7. Inventory email senders

List the services that send mail using your domain: your mailbox provider, product notifications, support desk, CRM, and newsletter tool. Check SPF, the DKIM selectors configured by those services, and DMARC. A missing sender in that inventory is more important than immediately switching a policy to its strictest setting.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector-from-your-provider._domainkey.example.com

8. Review public JavaScript for real secrets

Search your built assets locally for credential identifiers and unexpected environment values. Public configuration is not automatically secret: a publishable payment key differs from its server-side counterpart. If a privileged credential reached a browser bundle, revoke or rotate it and move its use behind an authenticated server boundary. Minification does not make a secret private.

9. Test your API’s CORS contract

Document which browser origins should read authenticated responses. Use exact scheme, hostname, and port comparisons where credentials are involved. Confirm that an unrelated origin receives no permission to read the response. Keep authentication and CSRF protection in place; CORS does not replace either.

10. Audit the dependencies you actually deploy

Run the audit supported by your package manager against the lockfile you build. Record the affected version, dependency path, available patch, and whether the vulnerable operation is reachable. Apply updates with application tests. An external fingerprint cannot provide the same evidence as your repository and dependency inventory.

npm ci
npm audit
npm audit --omit=dev

Review both results. Build tools can matter even when they are absent from the running server.

11. Reconcile DNS with active projects

Export your authoritative DNS records and compare them with hosting projects and their owners. Investigate CNAMEs pointing at retired services. Remove an obsolete record before deleting the resource it references, allowing for DNS caches. A scanner’s takeover warning is a lead to verify in your provider account, not proof that someone can claim the resource.

12. Check session cookie flags

Inspect the actual Set-Cookie response after signing in. Session cookies normally need Secure and HttpOnly; choose SameSite based on your login and cross-site integration requirements. Test OAuth callbacks and checkout returns after changing it. Avoid broad parent-domain cookies unless you need and understand that scope.

13. Review privileged access

Open the account lists for hosting, DNS, source control, databases, and payment administration. Remove obsolete memberships and require MFA where available. Replace shared administrator logins with named accounts. Store recovery information somewhere the team can reach if the primary operator is unavailable.

14. Prove you can restore

Choose a recent backup and restore it into an isolated environment. Check that the application starts and the important records are present. Record the restore steps, elapsed time, and dependencies. A successful backup job is useful evidence, but only a restore tells you whether it supports recovery.

15. Publish a monitored security contact

Add /.well-known/security.txt with a working contact and expiry date, and assign someone to maintain it. Follow RFC 9116 rather than inventing a reporting format. This gives a researcher a clear route to report an issue without guessing at an inbox.

Turn the checklist into a small work queue

Prioritize exposed credentials, broken access controls, and unavailable recovery paths before cosmetic grades. Separate immediate containment from durable fixes. For each completed task, repeat the original check and the relevant customer journey. Small business website security improves when these checks become part of releases and ownership, rather than a yearly spreadsheet nobody opens.

Check your own site — your first scan is free. Scanwise combines passive intelligence with non-destructive external HTTP, TLS, and TCP checks, highlights potential issues, and generates AI-assisted fix suggestions. It does not exploit findings or automatically change your site. Review and test suggested fixes; the starter credit requires a verified account and is subject to anti-abuse limits.