Website security checklist before launch

How to use this launch checklist

For each item, record one of three outcomes: checked with evidence, needs a fix, or not applicable with a reason. Record the deployment version and date too. An untested item should stay untested rather than becoming a pass because the app appears to work.

Use a staging environment and disposable data for tests that change records or trigger payments. The website security walkthrough explains how to run the checks. A free website scan is a useful starting point for the public-facing items; several checks below require source code, provider settings or manual testing.

HTTPS and browser protections

• HTTPS: The production domain has a valid certificate, HTTP redirects to HTTPS, and critical flows work without insecure active resources. Evidence: the redirect and certificate checks for the domains you actually use.
• Security headers: Document and sensitive-route responses have policies suited to your app. Review CSP, framing protection, HSTS and content-type handling. Evidence: saved response headers and a browser test confirming that required scripts and integrations still work.
• Session cookies: Cookies that carry authentication have attributes appropriate to the app, including Secure on HTTPS and HttpOnly when browser JavaScript does not need the cookie. Review SameSite behavior against your sign-in and payment flows. Evidence: cookie attributes checked in the production browser session.

Use MDN's HTTP cookie documentation to understand the attributes. Header and cookie configuration supplements application-level protections.

Secrets and production configuration

• Browser code: No private API keys, database passwords or service-role credentials are included in public JavaScript. Public identifiers have the intended permissions. Evidence: a scan or review of the production bundle and public environment variables.
• Repository and history: Secret checks cover the code, relevant history and configuration you intend to deploy. Revoke and rotate exposed credentials. Evidence: scan results and provider confirmation that old credentials are invalid.
• Deployment files: Debug settings, sample credentials, local environment files and backups are excluded from public deployment. Evidence: a review of build output and hosting settings for your own environment.

The exposed secrets guide explains why removing a key from the latest commit is only part of the fix.

Login, sessions and account recovery

• Signed-out access: Private API operations reject requests without a valid session. Evidence: requests to representative read and write endpoints made while signed out.
• Session lifecycle: Logout and session expiry behave as intended; an old session cannot continue accessing protected data after it is invalidated. Evidence: a retest using a disposable session.
• Password reset: Reset links are limited in lifetime and intended use, and cannot reset a different account. Evidence: tests with disposable accounts and an expired or already-used link.
• Abuse controls: Sensitive operations such as login, password reset and invitations have controls appropriate to their risks. Evidence: configuration review and controlled tests in staging.

These are manual workflow checks. A public URL scan does not sign in or prove that account recovery is safe.

Authorization and private data

• Two-account test: User B cannot read, edit or delete user A's private test records. Evidence: the same record requests made under both sessions, with the expected denial for B.
• Admin access: An ordinary account cannot call privileged operations directly. Evidence: server responses and confirmation that the operation did not happen.
• Invitations and roles: Users cannot assign themselves privileges or join another organization by changing a request field. Evidence: staging tests covering the roles your app supports.

See IDOR and missing admin authorization. Test the server's decision, including the resulting data state, rather than relying only on whether the UI shows an error.

Database and file storage

• Database rules: Exposed tables and collections have access rules that match your product's permissions. Evidence: deployed policies reviewed alongside repository configuration.
• Ownership: Rules distinguish a record's owner or organization from other signed-in users where required. Evidence: read and write tests as the owner, a second user and a signed-out visitor.
• Storage: Private uploads and generated documents cannot be retrieved by an unauthorized user. Evidence: direct download tests using disposable files and different accounts.

The database security guide and Supabase RLS guide cover common configurations. Provider references: Supabase RLS and Firebase rule pitfalls.

Payments, APIs and uploads

• Prices and entitlements: The server calculates prices and enforces purchased access using trusted data. Evidence: a staging request with a modified browser-supplied total that cannot change the amount charged or access granted.
• Webhooks: Payment events have their signatures verified and duplicate delivery does not duplicate an order, credit or entitlement. Evidence: tests using the provider's test tools.
• Input handling: Review database queries and other sensitive operations for unsafe input handling. Evidence: code review of the affected routes and relevant scan findings. See SQL injection.
• CORS: Allowed origins and credential settings match the clients that need access. Evidence: configuration review and tests from expected and unexpected test origins. CORS does not replace API authentication; see the CORS guide.
• Uploads: Permissions, size limits, permitted file types and storage behavior fit the feature. Evidence: controlled staging tests and configuration review.

Mark payment or upload items not applicable when your app has no such feature. SetRepo checks some code patterns in these areas; it does not execute every workflow above.

Dependencies and infrastructure

• Dependencies: Review known-vulnerability findings for the versions you actually deploy. Evidence: current manifests or lockfiles, scan results and a tested upgrade plan for affected packages.
• Production access: Hosting, repository and database administration access is limited to the people and services that need it. Evidence: a review of memberships, service accounts and credential storage.
• Domain and email: Domain ownership, DNS records and email authentication settings are reviewed where applicable. Evidence: provider settings and checks against your production domain.

The dependency guide explains how to investigate affected versions. An updated package still needs regression testing in your app.

Recovery and the release decision

• Backups: A recent backup has been restored into an isolated environment successfully. Evidence: the restore date, recovered data and the person responsible for recovery.
• Monitoring: Someone receives and can act on errors and security-relevant events. Logs avoid exposing credentials or unnecessary personal data. Evidence: a controlled alert test and logging review.
• Retest: Confirmed issues have a fix and a repeat of the original test against the deployed version. Evidence: the new result linked to the original finding.
• Remaining risk: Open findings and untested items have an owner and a release decision. A clean URL scan does not close source-code or manual-test items.

Begin with the free website security scanner, connect code for broader checks, and use the coverage page to identify work that remains. For a wider testing program, consult the OWASP Web Security Testing Guide.

FAQ

What security checks should I run before launching a website?

Check HTTPS, headers, secrets, login and account recovery, authorization, database and storage permissions, dependencies and recovery. Add payment, webhook and upload tests when those features exist. Record evidence and unresolved items for the deployment you will release.

Can an automated scan complete this whole checklist?

No. A URL scan covers publicly reachable signals. Source-code scanning adds checks of the code and configuration you provide. Two-account access tests, payment behavior, backup restores and administrative access reviews still need separate verification.

Which findings should I fix first?

Start with confirmed exposures that could leak secrets or private data, permit unauthorized changes, or grant paid access incorrectly. Consider exploitability and the sensitivity of affected data alongside the scanner's severity. Record other findings and skipped tests for follow-up.

Should I repeat these checks after launch?

Yes. Repeat relevant checks after changes to authentication, permissions, database rules, payments and dependencies. Recheck the production deployment after fixes, and keep recovery procedures current.