How do I check if my app is secure?

1. Can one user see or change another user's data?

This is the most common serious flaw in modern web apps, and it tops the OWASP Top 10 as broken access control. Create two accounts, A and B. Logged in as A, open your browser's developer tools, watch the network requests while you use the app, and note the IDs in them (an order number, a user ID, a project ID). Then, logged in as B, try the same requests with A's IDs. If B gets A's data, the server is trusting the ID instead of checking who is asking.

2. Are your database rules switched on?

If your app talks to the database straight from the browser, as Supabase and Firebase apps do, the database rules are your security. Supabase needs row level security turned on for every table, and Firebase needs security rules that check the signed-in user. See our Supabase and Firebase checklists for the exact steps.

3. Are any secret keys in your front end?

Anything sent to the browser is public. Some keys are meant to be public, such as a Supabase anon key, a Firebase config or a Stripe publishable key. Others must never be: a Stripe secret key, an OpenAI or Anthropic key, a Supabase service role key, cloud credentials or a database connection string. Our guide on API keys in the front end shows how to check.

4. Do your sign-up and login flows hold up?

• Password reset links expire and work only once.
• Email verification cannot be skipped by calling the next step directly.
• Login and password reset are rate limited, so nobody can try thousands of passwords.
• Logging out really ends the session on the server.

5. Are payments confirmed on the server?

Never unlock paid features because the browser says payment succeeded. Unlock them when your server receives a verified webhook from your payment provider. Then check that a free account cannot reach paid features by calling their requests directly.

6. Are admin pages protected on the server?

Hiding the admin menu is not protection. Every admin request must check, on the server, that the caller is an admin. Test it by sending an admin request while logged in as a normal user.

7. Are file uploads limited?

Limit the file types and sizes you accept, store uploads outside your app's code, and make sure private files cannot be opened by guessing their address.

8. Are your dependencies up to date?

Run your package manager's audit command (for example npm audit) and update anything with a known, fixable vulnerability.

When to get a second pair of eyes

These checks catch the common problems, but the assistant that wrote your code cannot independently check its own work, and some flaws only show up when someone tries to break the app on purpose. If real users or payments are involved, a person-checked security test is worth it before launch or before a big customer asks for one. Elitor offers a free check, and one-off checks from £249.