security testing checklist before launch

TL;DR

Before launch, verify the basics that cause most breaches: authentication actually enforced everywhere, inputs validated server-side, no secrets in code or logs, dependencies patched, security headers set, and backups tested. A checklist beats memory; run it the same way every release and keep the evidence.

The query

security testing checklist before launch

Use this when

• You are days from launching a web app, API, or major feature
• Someone asks "are we sure this is safe to ship"
• You want to turn one-off security reviews into a repeatable gate
• A pentest report just landed and you need to verify the fixes stuck

Not for

• A full penetration test (hire that separately for high-risk launches)
• Compliance audits like SOC 2 or PCI; this is engineering hygiene, not certification
• Responding to an active incident

Steps

1. Authentication and sessions: confirm every route requires auth except the ones you explicitly marked public. Test with no token, an expired token, and another user's token. Check session timeout and logout actually invalidates.

Expected output: a list of public routes you can defend, and 401/403 on everything else.

1. Authorization: for each role, try to reach another role's data and actions. IDOR checks: swap IDs in URLs and request bodies, confirm you only see your own records.

Expected output: no cross-user data access in any test.

1. Input handling: submit bad input everywhere users type or upload. Oversized payloads, wrong types, null bytes, path traversal strings in filenames, and HTML/script in text fields. Confirm the server rejects or neutralizes, never reflects raw.

Expected output: 400s and sanitized output; nothing executes, nothing escapes its directory.

1. Secrets and config: scan the repo and the built artifacts for keys, passwords, and tokens. Confirm production config comes from the secret store, not code or chat logs. Rotate anything that ever appeared in a log.

Expected output: scanner finds zero secrets; rotation log exists for anything historic.

1. Dependencies: run the package audit, review what is actually reachable (not just what is flagged), patch or pin, and record exceptions with dates.

Expected output: audit output triaged, not just printed; exceptions have owners and expiry.

1. Headers and transport: confirm HTTPS everywhere with HSTS, and set the standard security headers (content type options, frame options or CSP, referrer policy). Check error pages do not leak stack traces.

Expected output: header scan passes; error pages are generic in production.

1. Logging and monitoring: confirm auth failures, permission denials, and input rejections are logged with enough context to investigate, and that someone actually watches the alerts.

Expected output: a test attack produces log entries and fires the alert path.

1. Backups and rollback: restore the backup to a scratch environment and confirm the app runs. Confirm you can roll back the deploy.

Expected output: a restore you have actually done, not one you assume works.

Variant phrasings

"go-live security review"

Same checklist, run as a meeting: walk each item, name the evidence, record gaps as launch blockers or accepted risks with owners.

"web app security audit checklist"

Deeper version of the same list: add third-party script review, subdomain inventory, and DNS records. The shape does not change.

"API launch security checks"

Subset with API emphasis: auth on every route, rate limiting, mass-assignment review (extra fields in request bodies must not set privileged attributes), and schema validation.

Why this happens

Launches concentrate risk: new code, new infra, tired people, and a deadline. The bugs that bite after launch are rarely novel; they are the checklist items nobody verified because everyone assumed someone else did.

Edge cases and pitfalls

• Staging is not production: run the checks against prod-like config, real headers, and real secret handling.
• Third-party scripts and SDKs are part of your attack surface; inventory them like your own code.
• "We will fix it after launch" needs a name, a date, and a ticket, or it is a wish.
• Re-run the checklist after any hotfix that touches auth, input handling, or config; hotfixes skip process by design.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCstaRRSmCnV6p3oAjdZ3A