How do I check my app is secure before launch?

Also searched as: App security checklist · Application security checklist OWASP · Mobile app security checklist · Is my website secure test · App audit checklist

Updated 3 October 2026

Short answer

Check the handful of things attackers try first. Can one user see or change another user's data? How do logins and sessions work? Are any keys, databases or file stores open to the internet? Can what users type reach your database unfiltered? Can a payment be skipped or changed? Does anything stop someone hammering your login? Is everything on HTTPS? Do your dependencies have known holes? The OWASP Top 10 is the standard list, and broken access control is number one on it.

What's the problem

You're about to let strangers sign up, and you're not sure what they could do once they're in. Most MVPs are built to make the features work. Whether the features can be abused is a different question, and it usually hasn't been asked.

Why it happens

  • Access checks are easy to forget. The page only shows your own orders, but the server will hand over anyone's if asked for them directly.
  • Shortcuts made during building stay in. Open database rules, test keys, debug pages and admin routes without logins.
  • Every package is part of your app. An old project pulls in hundreds of other people's packages, some with published vulnerabilities.
  • Nothing has been tested the way an attacker would test it. Testing so far has been "does it work?", not "can I break it?".

How to fix it

Work through this list. Each item is something real attackers check.

  1. Access control. Log in as one user, then try to load another user's records by changing an ID in the address bar or in a request. It must fail. Every check has to happen on the server; hiding a button isn't a check.
  2. Logins. Passwords stored hashed with a modern algorithm, never readable. Password reset links that expire and work once. Sessions that end when you log out.
  3. Secrets. No API keys or passwords in frontend code or in the repository, including its history. Turn on secret scanning if you use GitHub.
  4. Data stores. The database isn't reachable from the internet, Firebase rules aren't in test mode, Supabase tables have Row Level Security on, and file storage isn't public unless it should be.
  5. Input. Database queries use parameters, not text glued together. What users type is escaped before it's shown. Uploads are restricted by type and size.
  6. Payments. Prices and "payment succeeded" are decided by your server and your payment provider, never by the browser.
  7. Rate limits on login, sign-up, password reset, and anything that costs you money per request.
  8. HTTPS everywhere, with http redirected.
  9. Dependencies. Run your package manager's audit (npm audit for JavaScript) and deal with what affects code that actually runs.
  10. Errors. Users see a plain message, never a stack trace or database error.

When to call Preventionlabs

If you can tick every item with confidence, launch. Call us when you can't, or don't know how to check. Protection to MVP level is one of the three things every resurrection delivers: authentication, access control, data exposure, injection, existing payment flows, rate limiting, HTTPS and dependency vulnerabilities, tested the way an attacker would test them, then fixed. It's not a formal penetration test or a compliance certificate, and we say so in writing.

Submit your project for a free assessment

Free assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.

Sources

  1. OWASP: OWASP Top 10:2025security standards bodyThe OWASP Top 10 is a standard awareness document for developers and web application security.
  2. OWASP: OWASP Top 10:2025security standards bodyA01:2025 - Broken Access Control
  3. OWASP: Password Storage Cheat Sheetsecurity standards bodyPasswords should be securely hashed using modern, adaptive hashing algorithms (e.g., Argon2id, bcrypt, or PBKDF2), rather than encrypted or stored in plaintext.
  4. GitHub: Secret scanningofficial docsSecret scanning scans your entire Git history on all branches of your repository for hardcoded credentials, including API keys, passwords, tokens, and other known secret types.
  5. npm: npm auditofficial docsThe audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities.

Related

Is my AI-built app secure? Don't assume so. Research found people using AI assistants wrote less secure code and were more confident in it. Check access control, keys and data first. I leaked an API key. What do I do? Revoke it and create a new one now, before anything else. Deleting it from the code doesn't help: it's still in the history. Then check what it was used for. Is it safe to keep login tokens (JWTs) in localStorage? It's a risk: any script on your page can read localStorage, so one injected script can steal every logged-in session. HttpOnly cookies can't be read by scripts. How much does a penetration test cost in Australia? Australian testing firms publish indicative prices from a few thousand dollars for a small web app to tens of thousands for bigger scopes. What sets the price.
← All of Is it safe?