BYTEASSUREStart a reviewLong security checklists tend to become background noise. A useful launch check is short enough to run, specific enough to produce evidence and clear about who can accept an unresolved risk.
This is the version I would want beside a release decision. It does not cover every control. It concentrates on mistakes that can turn a normal product launch into a data, payment or access incident.
Identity and sessions
- Sign-in, sign-out and account recovery work in a private browser.
- Passwordless links and reset links expire and cannot be reused indefinitely.
- Session cookies use secure production attributes.
- Sensitive account changes require appropriate recent authentication.
- Login and recovery endpoints have rate limits without revealing registered emails.
Record the actual test accounts and outcomes. “Authentication implemented” is not evidence that recovery or logout behaves correctly.
Authorisation and tenant isolation
- Every API action checks permission on the server.
- A user from organisation A cannot read or modify organisation B's records.
- Administrative roles are scoped to the correct organisation or resource.
- Direct requests to hidden routes receive the same checks as interface actions.
- Background jobs preserve and verify the tenant boundary.
Test at least one negative case for each sensitive workflow. The denial is the evidence.
Data and storage
- Supabase RLS, Firebase rules or API data policies match the role model.
- Private files are not available through predictable public URLs.
- Production backups exist, have a named owner and have been restored at least once.
- Logs avoid passwords, tokens, full payment payloads and unnecessary personal data.
- Data retention and deletion behaviour match what the privacy notice says.
Secrets and dependencies
- No privileged credential appears in browser assets, source maps or mobile bundles.
- Production secrets come from a managed secret store rather than the repository.
- Previously exposed credentials have been rotated, not merely deleted.
- High-impact dependency vulnerabilities have an owner and decision.
- Test keys and production keys cannot be confused by a silent fallback.
Payments and provider callbacks
- The server chooses the permitted product and price.
- Payment fulfilment begins only after a verified provider callback.
- Webhook signatures are checked against the raw body.
- Duplicate delivery cannot create a second order or entitlement.
- Refund, failure and pending states are represented truthfully.
Run one complete test-mode journey. A successful checkout screen is only an intermediate checkpoint; verify the durable order and downstream action.
Production exposure
- HTTPS redirects correctly and all intended hostnames have valid certificates.
- Debug routes, test accounts and development CORS settings are gone.
- Error responses do not reveal stack traces or private configuration.
- Security headers allow only the scripts and frames the product needs.
- Public storage, source maps and environment files have been reviewed deliberately.
Detection and recovery
- Someone receives alerts for payment, authentication and server failures.
- A request or order can be followed through logs using an opaque identifier.
- The team knows how to revoke a credential and disable a compromised integration.
- There is a rollback path for the release.
- Customer-facing incident language has an owner, even if it is only a short template.
How to use the checklist
Do not mark items complete because code exists. Attach one piece of evidence: a test result, policy, screenshot, log query or restored backup. Name unresolved items and the person accepting the launch risk.
Run the checklist again when the trust model changes. Adding team accounts, payments, a mobile client or an AI agent creates new boundaries even when the original launch was reviewed.
Attach the evidence to the release decision. That keeps unresolved assumptions visible to the person accepting the risk.