Contents6
When people think about app security, they think about a password a hacker might guess. That is rarely how data leaks. Most often, the app simply lets a signed-in user read what does not belong to them, because an access rule is missing somewhere. For a business owner, the right question is not “are our passwords complicated enough?”, but “who checks, on every request, that this person is allowed to see this data?”.
In short
Access control is the leading flaw in web applications: every request must be checked by the server.
Sign-in should match the use: an emailed code or a passkey is often better than a complicated password.
Secrets (API keys, admin keys) never live in the app installed on the phone.
Deleting an account, reporting a breach, restoring a backup: these are features to plan before launch, not after.
The first flaw: who is allowed to see what
The reference ranking of web application risks, the OWASP Top 10, puts broken access control at the top of its 2025 edition, ahead of security misconfiguration. Authentication failures only come seventh.
Definition
Access control
The set of rules that say, for each piece of data, who can read, change or delete it. A customer sees their own invoices, not their neighbour’s; a technician sees their own jobs, a manager those of their team.
The trap is to let the screen carry these rules. Hiding a button protects nothing: anyone who knows the data’s address can ask the server for it directly. The rule must live on the server, as close to the database as possible. With Supabase, for example, these are row-level security policies: its documentation asks you to enable them on every exposed table, and states that once enabled, no data is accessible through the public key until a policy allows it.
Watch out
What happens when the rule is missing
In May 2025, vulnerability CVE-2025-48757, scored 8.26 out of 10, affected apps generated by the Lovable platform: with no access policies on some tables, the app’s public key was enough to read names, email addresses, third-party API keys, and sometimes to change a payment status. We come back to these incidents in our article on vibe coding.
It is also one of the deeper arguments in choosing between Supabase, Firebase or your own server: each expresses these rules its own way, and none writes them for you.
A sign-in that matches the use
Sign-in is the app’s front door, and every extra step loses users. The right sign-in depends on what the app protects.
- No account, when possible. Apple asks for it in guideline 5.1.1 of its App Review Guidelines: if the app has no significant account-based features, people must be able to use it without signing in.
- A link or a code by email. No password to remember: the user receives a one-time link or a six-digit code. At Supabase, they expire after one hour by default, according to its passwordless sign-in documentation.
- Passkeys. Sign-in uses the phone’s unlock, with no secret to type or steal. Revision 4 of NIST’s digital identity guidelines, released in July 2025, integrates synced passkeys, according to its overview.
- A password, when needed, but following current rules, which have changed a lot.
at least for a password used as the only sign-in factor
at least when it is combined with a second factor
imposed: no more requirement to mix upper case, digits and symbols
The same document forbids requiring periodic password changes, unless there is evidence of compromise, and requires rejecting common passwords or those already seen in breaches.
From the field
In Challenge Us, a first name is enough to start
Challenge Us, a group-challenge app we built, only asks for a first name to get in; an email or a recovery code are optional. On iPhone, the installed app does not share its session with the browser, so it shows the recovery code before explaining installation to anyone who has not linked an email. A simple entry does not stop the rules from being enforced by the server, down to the date of each entry, which the phone’s clock cannot backdate.
Secrets do not live on the phone
Anything shipped in the app (the screen code, its files) can be read by a curious user. A paid API key, a database admin key or a service credential therefore have no place there. Supabase says it plainly: its secret key bypasses access policies and must never be in the browser or exposed to customers.
Anything that needs a secret goes through a server-side function, which makes the call and only returns the result. That holds for a payment, for sending an email, for calling an AI model. The subject goes beyond apps: our article on secrets vaults shows how tools can use secrets without ever seeing them.
What your users’ data requires
An app that creates accounts processes personal data, with specific obligations.
- Account deletion inside the app. Apple requires it of any app that lets people create an account, in the same guideline 5.1.1. Deleting means erasing the data, not just hiding the profile.
- Asking only for what is needed. Again according to Apple, an app may only require personal information when it is relevant to its core function or required by law. The GDPR says the same under the name of data minimisation.
- A breach plan. Article 33 of the GDPR requires notifying a personal data breach to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. Who alerts whom, with which logs, is decided beforehand.
- Restorable backups. A lost database is a security incident too. A backup that has never been restored protects nothing, as shown in what really breaks with backups.
What to ask your provider
- The access map.
For each type of user, what they see, change and delete, written before development.
- Tests of those rules.
A test that signs in as customer A and checks it reads nothing of customer B, rerun with every release.
- The secrets inventory.
Where each key lives, who can access it, how it is rotated if it leaks.
- The deletion and breach paths.
How a user deletes their account, how the team responds to a breach.
These points are decided at scoping, which is when they cost least: a forgotten access rule takes one line to fix before launch, and a notification to the authority after. They are part of what makes the price of an app vary, especially when several roles coexist, as in a client portal or an app for field teams. And they are followed over time, with library updates counted in the maintenance budget.
Our app development service has access rights enforced by the server, not by the screen: what must be right, such as a counter, a date or an access right, does not depend on the phone.
Frequently asked questions
Should users be forced to create an account?
No, if the app can do without one: Apple asks that an app without significant account-based features be usable without signing in. When an account is needed, a light entry (a link or a code by email) loses fewer users than a full form, and it removes the forgotten-password problem at the same time.
Is a complex password safer?
Not necessarily. The NIST guidelines released in July 2025 favour length (at least 15 characters for a password used alone), forbid imposing a mix of character types or periodic changes, and require rejecting passwords already seen in breaches. A passkey or an emailed code often does better still.
Is an app generated by AI less secure?
Not by nature, but nobody checks for it who is allowed to read what. Vulnerability CVE-2025-48757, in 2025, came from missing access policies in generated apps: a human review of the rules and access tests remain essential, whoever or whatever wrote the code.
What should we do if an app’s data leaks?
Contain the leak (rotate the keys, fix the rule), assess the risk to the people concerned, then notify the supervisory authority within 72 hours if that risk exists, as Article 33 of the GDPR requires. The people concerned must also be informed when the risk is high. All of this is prepared before launch.
Sources
- OWASP Top 10:2025 (new tab)top10.owasp.org
- Supabase docs, Row Level Security (new tab)supabase.com
- Matt Palmer, CVE-2025-48757 (new tab)mattpalmer.io
- Apple, App Review Guidelines (new tab)developer.apple.com
- Supabase docs, passwordless email sign-in (new tab)supabase.com
- NIST SP 800-63, revision 4 (new tab)pages.nist.gov
- General Data Protection Regulation, EUR-Lex (new tab)eur-lex.europa.eu
Jim · founder of Brain Plus AI
Also in web and mobile apps
Choose and price6 min
App back end: Supabase, Firebase or your own server
Behind an app’s screens you need accounts, a database, files and rules. Supabase, Firebase and your own server answer this in three ways, and each commits you to different things.
Understand6 min
Client portal: giving clients access to their files
“Where is my file at?”, “Could you resend the invoice?”: a client portal answers these questions without a call or an email. Here is what it changes, three ways to get one, and the rule that keeps it safe.
Stepping back22 min
Vibe coding: AI codes fast, the product stays human
AI has removed real technical barriers, but it has not removed what makes a product. What is true and what is false in "anyone can do anything with computers", with examples in both directions.