Security
Five Security Checks Every New App Should Pass Before Launch
Five practical checks that close common weaknesses in a new app, without turning launch into a security project.
A2S Venture team · November 13, 2026
1. Sign-in and permissions
Check who can sign in and what each person can reach. Admin pages should not be open to every account, and no one should share a login.
Turn on two-factor sign-in for admin users, and give people the least access they need to do their job. Test the unhappy path too: what happens when someone opens a page they should not see?
2. Secrets and production settings
Keys, passwords and API tokens should live in environment settings, never in the code or a public repository. Rotate any key that has been shared in a chat or a document.
Before launch, check that debug pages and detailed error messages are off in production, and that admin tools are not reachable from the public site.
3. Inputs and uploads
Every field that accepts data needs limits: length, type and format. Use your framework’s built-in protections for database queries and page output rather than building them by hand.
If the app accepts files, restrict the types and size, store uploads away from the code, and check them before anything else reads them.
4. Dependencies and response headers
Run a dependency scan, remove libraries you no longer use and apply the updates that fix known issues. Put this check in the release routine so it does not depend on someone remembering.
Serve the app over HTTPS, add the common security headers and rate-limit sign-in and form endpoints. These close easy routes for automated abuse without changing the product for real users.
5. Backups and a response plan
A backup that has never been restored is only a hope. Restore one into a test environment and note how long it takes and what is missing.
Write down who watches alerts, who makes decisions and how you would tell customers if something happened. A short, tested plan is worth more than a long document nobody has read.