App security checklist before you launch

Before launching a web or mobile app, check seven areas: login and sessions, access control on every server endpoint, how secrets like API keys are stored, input validation, third-party dependencies, backups, and logging with alerts. Most real-world breaches of small and mid-size apps come from a few repeat mistakes, such as an API that returns other users' data when you change an ID, a database left open to the internet, or a secret key shipped inside the app. Catching those takes days, not months.

You don't need to be a security expert to run through this list with your developer. You need to ask each question and expect a clear answer.

1. Login, passwords and sessions

• Passwords are stored hashed with a modern algorithm, never in plain text or reversible encryption.

• Login is rate-limited, so attackers can't try thousands of passwords.

• Password reset links expire quickly and work once.

• Error messages don't reveal whether an email is registered.

• Sessions expire, and logging out actually ends the session on the server.

• Admin accounts use two-factor authentication.

Using a proven authentication service, like Supabase Auth, Firebase Auth, Auth0 or Clerk, covers much of this and is usually safer than writing your own.

2. Access control on every endpoint

This is the most common serious flaw we find. The app's screens only show a user their own data, but the server's API doesn't check. Change an order ID in a request, and you see someone else's order.

Check that:

• Every API endpoint verifies who the user is and whether they're allowed to see or change that specific record.

• Admin functions are protected on the server. Hiding a button in the interface protects nothing.

• Database security rules are enabled and tested, if your app talks to the database directly, as with Supabase or Firebase.

• File uploads and downloads check permissions too.

Test it the simple way: log in as one user, copy a request, change the ID to another user's record, and see what happens.

3. Secrets and configuration

• API keys, database passwords and payment secrets live on the server, in environment variables or a secrets manager, never in the code repository.

• Mobile apps and websites contain no secret keys. Anything shipped to a phone or browser can be read.

• Keys have the minimum permissions they need, and there's a plan to rotate them.

• Debug modes and test accounts are off in production.

4. Input, output and uploads

• Every input is validated on the server, whatever the app's own checks say.

• Database queries use parameters, not text pasted into query strings, to prevent SQL injection.

• User content shown on pages is escaped or sanitised, to prevent cross-site scripting.

• File uploads are limited by type and size, stored outside the web root, and scanned if they're shared with other users.

The OWASP Top 10 for web apps, and the OWASP Mobile Application Security guidance for mobile, list these risks in more detail and are worth having your developers read.

5. Dependencies, infrastructure and recovery

Dependencies

Modern apps use hundreds of open-source libraries. Run an automated check for known vulnerabilities, such as npm audit, Dependabot or Snyk, and update anything critical before launch. Remove libraries you don't use.

Infrastructure

• Databases aren't reachable from the public internet.

• HTTPS everywhere, with security headers like a content security policy on web apps.

• Cloud storage buckets aren't public unless they're meant to be.

• Access to production servers and dashboards is limited to named people with two-factor authentication.

Backups and monitoring

• Automatic backups, stored separately, and a restore you've actually tested.

• Error tracking and logs for logins, permission failures and admin actions.

• Alerts that reach a person when something unusual happens, like a spike in failed logins.

• A written plan for what to do if there's a breach. Under India's DPDP Act, for example, the Data Protection Board expects a detailed report within 72 hours, as covered in our DPDP compliance checklist.

When to get a professional test

For apps handling payments, health data, financial data or large amounts of personal data, add a penetration test by an independent tester before launch and after major changes. It costs a fraction of a breach, and enterprise customers often ask for the report.

For smaller apps, a careful review against this checklist catches most problems. We run it on every web and mobile app we build, and it's the first thing we check when we take over an app someone else built, especially apps assembled quickly with AI tools, as we describe in the vibe coding rescue guide.

Questions about app security

How much does an app security audit cost?

A code and configuration review against a checklist like this is a modest, fixed-scope job. A professional penetration test costs more and varies with the size of the app. Both cost far less than recovering from a breach.

Is my app secure if I use Firebase or Supabase?

The platforms themselves are secure, but your app's security rules decide who can read and write data. Misconfigured rules are one of the most common causes of data leaks in apps built on these platforms.

How do I know if my app has been hacked?

Signs include unusual logins, unexpected admin actions, spikes in traffic or errors, and data appearing where it shouldn't. Logging and alerts are how you find out early instead of from a customer or a journalist.

Should I store customer data in India?

It depends on your sector and customers. The DPDP Act allows transfers abroad except to countries the government restricts, while some sectors, like payments, have their own local storage rules. Check the rules for your industry.

Get a pre-launch security review

If you're about to launch, or you've inherited an app you're not sure about, ask us for a security review. We'll check it against this list and give you a clear report with fixed prices for any fixes.