Before launching a static site, confirm that dependencies are scanned and pinned, no secrets reach the bundle, functions and forms are reviewed, security headers and HTTPS are in place, DNS records point at things you control, third-party embeds are listed, and you can roll back quickly. Tick each item below.
Checklist
Code and dependencies
- Lockfile committed, CI installs from it.
- Dependency scan run with no unexplained critical findings.
- Build-time and shipped packages identified.
- Unused plugins and packages removed.
- Install scripts reviewed or disabled where practical. See malicious postinstall scripts in npm packages.
Secrets and tokens
- Built output searched for key strings.
- Public-prefix environment variables reviewed one by one.
- CMS and API tokens scoped to the least access that works. See headless CMS tokens on a static site.
- Repository history checked for old tokens, and any exposed one rotated.
Functions and forms
- Each function has its own scan and an owner.
- Input validated on the server.
- Form handler vetted. See how to vet a third-party form handler.
- CORS rules reviewed for browser callers.
Hosting and DNS
- HTTPS enforced, with a redirect from HTTP.
- Security headers present on HTML responses. See HTTP security headers explained.
- Redirect and header rules reviewed. See how to review redirect and header rules.
- Every DNS record points at a service you still use. See dangling DNS and subdomain takeover.
- Preview deployments protected or deleted.
Third parties
- Every external script and embed listed with an owner.
- Iframes use sandbox, a referrer policy and lazy loading where suitable.
- Subresource integrity used for pinned third-party files. See subresource integrity explained.
- Tag manager access limited and logged.
Search and content
- Search index contains no drafts or unlisted pages. See what a client-side search index leaks.
- Content pull requests reviewed like code if you use MDX.
Operations
- Build hooks stored as secrets and scoped.
- A rollback to the previous deploy tested once.
- A cache purge procedure written down.
- A scheduled rescan of dependencies in place.
- A security contact published, for example a security.txt file.
- An owner named for the site's security.
How to use this list
Treat it as a launch gate. Assign each item to a person, give it a date, and keep the completed list with the release record. If an item cannot be done before launch, write down the reason and the date you will revisit it. Anything unchecked is a decision, not an oversight.
Try it yourself
The pull request gate demo shows how a policy blocks a change that adds a serious finding. Use it as a model for checklist items 2 and 28.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard covers the scanning, SBOM and gating items on this list, and its asset discovery helps with the inventory. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Do I need all thirty items for a small brochure site?
Not all of them apply. Skip the sections you have no function or embed for, and keep the ones about dependencies, headers and DNS.
How long does a first pass take?
For a small site, a few hours, mostly spent finding tokens, scripts and DNS records nobody remembered.
Last reviewed: 19 October 2026.
