Practical launch guide
Verify a website before launch with live checks for exposed files, JavaScript secrets, source maps, TLS, headers, cookies, DNS, and forms.
How to use it
Repository review and platform dashboards are necessary, but users receive the deployed site. Work through the list after the final build, domain, redirects, environment values, and API routes are in place. Record anything you cannot verify as unknown rather than treating it as passed.
Choose the canonical apex or www host, permanently redirect every alternative in one hop, and align canonicals, sitemap URLs, Open Graph URLs, internal links, checkout returns, and auth callbacks.
Verify that environment files, repository metadata, database dumps, backups, logs, source configuration, debug pages, and admin utilities were not copied into the public directory.
Search the code browsers actually receive for secret keys, private tokens, server-only environment values, internal endpoints, and temporary authorization shortcuts.
Decide whether production maps should be public. If error monitoring needs them, upload maps privately and remove them from the public artefact when confidentiality matters.
Use a valid certificate for every production hostname, disable legacy protocols where possible, redirect HTTP to HTTPS, and add HSTS only after every intended subdomain supports HTTPS.
Deploy a tested Content Security Policy, clickjacking protection, content-type protection, a deliberate referrer policy, and a permissions policy appropriate to the application.
Use Secure, HttpOnly, and appropriate SameSite settings; avoid credentials in GET requests; validate redirects against an allowlist; and enforce authorization on the server for every sensitive action.
Treat public function routes as public APIs, keep privileged keys server-side, apply least-privilege database grants, and test Row Level Security and storage policies independently of the website scan.
Review authoritative nameservers, DNSSEC, CAA, SPF, DKIM, and DMARC. Confirm renewal, auto-renewal, billing contacts, and registrar account protection.
Enable production error and security logging without recording secrets, publish a responsible-disclosure contact, set rate and cost alarms, and write a short incident and credential-rotation procedure.
Ship blocker
Remove public access, rotate affected credentials, review logs, correct the build boundary, and retest before sending traffic.
Not a ship blocker by itself
Prioritise confirmed evidence and affected behavior. A public Supabase publishable key, an informational technology marker, or a passive coverage warning is not automatically a vulnerability.