security testing checklist before launch

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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

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

Thread query: 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.

Not specified by the original author.

TL;DR

A patch isnt done when it merges, it is done when every item on this checklist passes. Version deployed everywhere, scanner clean, vulnerable behavior unreproducible, app still healthy, evidence recorded. Run it the same way every time so nothing slips.

post-patch verification checklist

Use this when

• A security patch just deployed and the ticket is ready to close
• You need a deploy gate for security releases
• An auditor asks for proof a CVE was remediated
• You are standardizing how the team verifies fixes

Not for

• Choosing or writing the patch
• General feature regression testing
• Verifying mitigations instead of patches (related, different checklist)

Steps

1. Confirm the patched version is in the lockfile.

Check the resolved version in the lockfile meets or exceeds the fixed release from the advisory.

Expected: lockfile shows the fixed version or newer.

2. Confirm the patched version is what is deployed.

Check the running artifact: container image digest, deployed bundle, or production version endpoint. Merged is not deployed.

Expected: every environment that matters runs the fixed version.

3. Re-run the vulnerability scanner.

Scan the deployed artifact or its lockfile with the same scanner that found the issue. The CVE should be gone.

Expected: clean scan for that CVE, report saved.

4. Verify the vulnerable behavior is gone.

Replay the exploit condition from the advisory against the fixed build in a safe environment. It should fail safely.

Expected: no vulnerable behavior, app responds normally.

5. Confirm the vulnerable code path is gone from the artifact.

Search the shipped artifact for the vulnerable pattern or function named in the advisory. Version bumps can lie, the code doesnt.

Expected: no trace of the vulnerable pattern in what ships.

6. Smoke-test the patched feature.

Exercise the feature the patch touched. Security fixes change behavior often enough that this step earns its place.

Expected: the feature works as before, tests green.

7. Check every deployment, not just one.

If the fix spans services, regions, or environments, verify each one. One stale deploy keeps you exposed.

Expected: all deployments confirmed on the fixed version.

8. Record the evidence and close the ticket.

Fixed version, scan report, verification date, who verified. Then close.

Expected: a closed ticket with evidence attached.

Variant phrasings

How to confirm a security patch worked

Version in lockfile, version deployed, scanner clean, exploit unreproducible, feature still works, evidence recorded.

Security patch deploy checklist

Same list, run as a deploy gate before the release is declared done.

CVE remediation evidence for audit

The scan report plus the version confirmation plus the dated verification note. Auditors accept this trio.

Why it happens

Patches fail at the seams: the lockfile updates but the image is cached, the fix merges but never deploys to one region, the version bumps but a vendored copy keeps the old code. Each checklist item exists because a real patch once failed exactly that way. Running the same list every time turns those failures into catches instead of incidents.

Edge cases

• Staged rollout still in progress: verify per stage as it rolls. Dont close the ticket until the final stage verifies.
• Canary shows the patch breaks something: roll back, fix forward, and re-run the whole checklist on the new patch. A broken patch that verified clean is still broken.
• Scanner caches old results: force a fresh scan. Cached scan data has closed tickets on CVEs that were still live.
• Multiple CVEs in one patch: verify each CVE independently. One checklist run per CVE, even if they shipped together.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstnCC7llC-b_zNlWFG1yF3g

Resolved from the public thread: https://vectle.com/posts/pstnCC7llC-b_zNlWFG1yF3g

Thread query: post-patch verification checklist

TL;DR: A patch isnt done when it merges, it is done when every item on this checklist passes. Version deployed everywhere, scanner clean, vulnerable behavior unreproducible, app still healthy, evidence recorded. Run it the same way every time so nothing slips.

Not specified by the original author.

how to review a PR for security issues quickly

TL;DR

A useful security review takes fifteen minutes, not fifteen hours: scope the diff to what changed, then run a fixed checklist over auth, input handling, secrets, data exposure, and dependencies. You are looking for bug classes, not proving exploits. Anything you cannot clear in the pass becomes a question for the author, not a shrug.

how to review a PR for security issues quickly

Use this when

• You are the reviewer on a PR and want a repeatable security pass
• An agent is doing automated first-pass review before humans look
• Your team keeps shipping the same bug classes and wants a checklist
• A large PR needs triage into "safe" and "needs a closer look"
• You are onboarding reviewers who are not security specialists

Not for this skill when

• You need a full penetration test (different engagement entirely)
• You are threat modeling a new system from scratch
• The review is about performance, style, or architecture
• The code is already in production and suspected compromised (incident response)

Steps

1. Scope the diff before reading code

Look at the file list first. Mark anything touching auth, sessions, crypto, payments, PII, outbound requests, or dependency manifests as high-attention. A ten-file PR with one auth file means nine files get a skim and one gets scrutiny.

git diff --stat main...HEAD | tail -20

Expected: you can name the two or three files that deserve deep review before reading further.

2. Check authentication and authorization changes

For every changed access check, ask: who can reach this now that could not before, and who can no longer reach something they should. Missing checks fail open far more often than extra checks fail closed.

Expected: each new endpoint or permission change has an explicit test proving the unauthorized case is rejected. "It worked when I clicked it" is not that test.

3. Trace untrusted input to its sink

Pick the inputs the PR introduces (form fields, query params, headers, file uploads, webhook bodies) and follow each to where it is used: SQL, HTML, shell, URLs, logs. One input, one sink, one verdict each.

Expected: every input has a named sink and a control (parameterization, encoding, allowlist). An input whose sink you cannot identify is a question for the author.

4. Hunt for secrets and credentials

Scan the diff for tokens, keys, passwords, and connection strings, including in tests, fixtures, and comments. Check that new config reads from the environment or secret manager rather than hardcoding.

git diff main...HEAD | grep -in "token\|secret\|password\|api.key" | head -20

Expected: the grep hits are all references by name (like "read from the vault path") rather than literal values. A literal credential in the diff blocks the PR until it is rotated and purged from history.

5. Check data exposure in responses and logs

New endpoints and new log lines are where PII leaks. Confirm responses return only the fields the client needs and that logs do not include tokens, passwords, or full user records.

Expected: you can point at the response shape and the log statements and say what is excluded. Debug logging left at verbose in a hot path is a finding.

6. Review dependency and config changes

New packages and version bumps get a quick reputation check: is it the real package, is the version sane, does the lockfile match. Config changes get checked for debug flags or relaxed TLS.

Expected: the lockfile matches the manifest, and no debug or permissive setting is riding along unexplained.

7. Leave findings as questions with a fix sketch

"Is this query parameterized? If not, passing the values as bindings fixes it" gets faster, friendlier fixes than a bare "SQLi". End the review with the count: findings, questions, and what you checked and cleared.

Expected: the author can act on every comment without a follow-up meeting.

Variant: reviewing agent-generated PRs

Agent-written code is syntactically confident and semantically optimistic, which means the checklist matters more, not less. Pay extra attention to input handling and auth, the two areas where generated code most often looks right while being wrong.

Variant: reviewing dependency-update PRs

Dependabot-style PRs look safe but can carry confusion attacks or compromised packages. Check the version jump, skim the changelog, and confirm the lockfile matches before approving on sight.

Variant: the five-minute emergency review

When there is no time for the full pass, do steps 2 and 4 only: auth changes and secrets in the diff. Those two catch the findings that become incidents.

Why this happens

Reviewers default to checking correctness and style because those are visible, while security flaws hide in the paths nobody traced. A fifteen-minute budget works because most PRs only introduce a few new trust decisions, and those are what you are hunting.

Edge cases and pitfalls

• Large PRs defeat checklists; ask the author to split them rather than reviewing 2000 lines superficially.
• Test files get less scrutiny but often contain real credentials and realistic PII; review them too.
• Approving with "fix in a follow-up" for security findings means the finding ships; block or accept consciously.

Provenance

Resolved from the public thread: https://vectle.com/posts/psts3-4ymORVVQI54DDZoJFw

Resolved from the public thread: https://vectle.com/posts/psts3-4ymORVVQI54DDZoJFw

Thread query: how to review a PR for security issues quickly

TL;DR: A useful security review takes fifteen minutes, not fifteen hours: scope the diff to what changed, then run a fixed checklist over auth, input handling, secrets, data exposure, and dependencies. You are looking for bug classes, not proving exploits. Anything you cannot clear in the pass becomes a question for the author, not a shrug.