A Web Application Security Release Checklist

What this addresses

A security review is useful only when it addresses the features changed in the release. Static scans are necessary inputs but do not prove that approval boundaries, sessions or business rules still work.

Practical implementation steps

• Enumerate new routes and trust boundaries
• Review authentication, authorization and untrusted rendering
• Validate dependency and secret exposure checks
• Test security headers and input limits
• Record remediation, approval and rollback evidence

Acceptance test

Attempt an unauthorized update, stored-script payload and oversized request against changed endpoints; all should be handled safely with no private data returned.

Common failure mode

Do not interpret a zero-vulnerability dependency scan as proof of absence of application-logic flaws.

Define what the release changes

A useful release review begins with the actual diff and deployment plan. Identify new public routes, changed permissions, database migrations, external calls and any new way content enters the system. A cosmetic page update and a new upload endpoint need different checks. Record which existing controls protect each changed path, such as server authorization, request validation and same-origin enforcement. An unchanged login system can still be bypassed if a new administrative endpoint forgets to call its authorization helper.

Test the boundaries introduced by the feature

For a content editor, exercise stored script attempts, dangerous URL schemes, draft access and publication privileges. For a contact setting, verify that hidden values are absent from public APIs, server-rendered HTML and structured data. For a data endpoint, test the object and tenant boundaries rather than only the happy path. Use realistic requests to the built server so that routing, serialization and headers are included. Unit tests are valuable for validators, but they cannot establish that every route invokes the validator or rejects an unauthorized session.

Keep dependencies and configuration in the same review

Inspect the lockfile and dependency audit for the exact artifact being built. Distinguish runtime exposure from development-tool findings without ignoring either. Avoid a forced dependency repair that downgrades a framework security fix or changes unrelated application behavior. Review security headers against the features being introduced: adding a media domain, inline script or iframe allowance should have a specific reason and a bounded source. A header’s presence alone does not prove the application resists injection; the rendering path and policy behavior both matter.

Rehearse the deployment and rollback

Use an isolated environment with disposable or appropriately protected test data. Verify migrations are additive or otherwise have a reviewed data-preservation plan, and test the documented production build mode. Keep code, dependencies, compiled assets and runtime configuration aligned. Define service health checks, the decision to stop or continue and a rollback procedure that does not casually reverse new production data. A successful build is evidence about compilation, not evidence that a live integration, background worker or database role has the permissions it needs.

Close the release with explicit evidence

Record the tested commit, environment, commands and observed results. Separate implemented, tested, deployed and blocked items. Perform authorized live checks after deployment, including the lead form or customer journey touched by the change. If an external account, production backup or browser tool is unavailable, report that limit rather than borrowing a result from another environment. Resolve newly introduced high-impact security issues before release and track inherited issues with their practical exposure. The review should let another engineer understand why the artifact is releasable and exactly which assumptions remain unverified.