RUSHING TECHNOLOGIES
PRE-LAUNCH APPLICATION SECURITY CHECKLIST

Use this as a release conversation starter, not a substitute for a penetration test.

[ ] AUTHENTICATION
    [ ] Access and refresh tokens have short, intentional lifetimes.
    [ ] Refresh tokens are protected from JavaScript access.
    [ ] Password reset and login attempts are rate limited.
    [ ] Every protected route checks authorization, not just authentication.
    [ ] Account recovery does not reveal whether an account exists.

[ ] INPUTS AND APIS
    [ ] Request bodies, query parameters, and uploads are validated server-side.
    [ ] Database queries are parameterized or safely handled by an ORM.
    [ ] CORS allows only the origins the product actually needs.
    [ ] Public endpoints have abuse and rate-limit controls.
    [ ] Error responses do not expose secrets, stack traces, or internal IDs.

[ ] PAYMENTS AND WEBHOOKS
    [ ] Webhook signatures are verified before state changes are accepted.
    [ ] Webhook handlers are idempotent.
    [ ] The server, not the client, is the source of truth for entitlements.
    [ ] Refund, cancellation, and failed-payment paths have been tested.

[ ] SECRETS AND DEPENDENCIES
    [ ] No credentials are committed to the repository or shipped to the client.
    [ ] Production secrets are stored in the platform secret manager.
    [ ] Dependencies are scanned and lockfiles are committed.
    [ ] Exposed credentials have a documented rotation path.

[ ] DEPLOYMENT AND OBSERVABILITY
    [ ] HTTPS, secure headers, and a restrictive content policy are configured.
    [ ] Production errors are monitored and actionable.
    [ ] Backups or recovery procedures have been tested.
    [ ] The team knows how to pause risky integrations and revoke access.
    [ ] The release has a written rollback plan.

If several boxes are uncertain, request an Application Security Snapshot:
https://rushingtechnologies.com/harden.html

Rushing Technologies — direct engineering and security hardening.