Your App Leaks the Same Data a Website Does

There is a persistent idea that a mobile app is inherently more secure than a website. It is installed, it is reviewed by a store, it runs in a sandbox.

All true, and none of it addresses where the data actually is.

An app is a client talking to an API. The data lives on the server, travels over the same network, and is stored in the same kind of database as the website’s. What the sandbox protects is the device. It does nothing for everything the app sends and receives.

With 1,205 notifiable breaches recorded in Australia in 2025 and 59% attributed to malicious or criminal activity, this is worth being concrete about. The figures themselves, and what they do and do not support, are taken apart by Cloud Geeks.

The four places apps actually leak

1. The API, with no authorisation check.

The most common and most serious. An app requests /api/orders/1042 and displays the result. Change the number to 1043 and the server returns somebody else’s order — because the check that the requesting user owns that record was never written, on the assumption that the app would only ever ask for its own.

An API is a public interface. Anyone can call it directly, with any parameters, regardless of what your app does. The rule is that every request must be authorised on the server, not filtered on the client.

2. Secrets shipped inside the binary.

API keys, tokens and credentials compiled into the app. They are not hidden — an installed app can be unpacked, and this is the first thing anybody looking does. A key in a mobile binary is a published key.

3. Third-party SDKs.

Analytics, crash reporting, advertising, mapping. Each receives data, each has its own policy, and each is something you declared or failed to declare to the store. This is where a privacy declaration most often becomes false without anybody deciding anything — a dependency update adds a data flow nobody chose.

4. Data at rest on the device.

Tokens, cached responses and personal details written to ordinary storage rather than the platform’s secure store. Less catastrophic than the API cases, and it matters on a shared, lost or backed-up device.

★ Insight ------------------------------------- Three of the four are not really mobile problems. They are server and supply-chain problems that arrived with the app. Which is why “we had a security review of the app” often misses them — the review looked at the client, and the data is behind the API. The question worth asking a developer is not whether the app is secure, but whether the API would be safe if the app did not exist. -------------------------------------------------

Why the app is held to a higher standard than your website

This is the part that surprises businesses shipping their first app.

Your website has a privacy policy. It is a document, and nobody checks it against the site’s behaviour unless there is a complaint.

Your app has a store declaration: a structured set of answers about what data you collect, why, whether you share it, and whether users can delete it. Both major stores now check those answers against observable behaviour, automatically. A mismatch is a policy violation found after release.

So the same data practice that sits unexamined behind a website becomes an enforceable, checked statement when you ship an app. That is not a reason to avoid apps. It is a reason to fix the data practice — and, in our experience, shipping an app is what finally forces businesses to find out what their systems actually collect.

What a small business should ask

Five questions for whoever built or maintains your app. None require technical knowledge to ask, and the quality of the answers tells you most of what you need.

1. If someone called our API directly, pretending to be a different customer, what stops them seeing that customer’s data? The answer must describe a server-side check. “The app wouldn’t do that” is the wrong answer.
2. Are there any keys or passwords inside the app itself? If yes, what would happen if they were public — because they effectively are.
3. Which third-party libraries receive customer data, and does our store declaration list all of them?
4. Where are login tokens stored on the device? The answer should name the platform’s secure storage.
5. If we had a breach, could we tell which customers were affected? This is a logging question, and it determines whether a notifiable breach can be scoped inside the 30-day assessment window.

The cheapest test you can run

You do not need a penetration test to find the most serious of the four.

Ask your developer to demonstrate, on a test environment, what happens when the app requests a record belonging to a different user. Not describe it — show it, with the request and the response on screen.

If the server returns the record, you have found the most common and most serious mobile data flaw in about ten minutes, and you have found it before somebody else did.

If the server refuses, ask how. The answer should describe a check performed on the server against the authenticated user. If the answer is that the app only requests its own records, the test has not been understood, because the whole point is that the request did not come from the app.

The relationship to the breach obligations

If your app holds personal information and your business is covered by the Privacy Act, an app breach is a notifiable breach on the same terms as any other. The same 30-day assessment, the same trigger at suspicion rather than confirmation, the same requirement to tell affected people what to do.

And from 1 July 2026, coverage extends to entities that became reporting entities under the second tranche of the anti-money-laundering regime, regardless of turnover — real estate agents, conveyancers, accountants, lawyers. Several of which are exactly the businesses currently commissioning client-facing apps.

The honest summary: an app does not change your data risk. It makes it explicit, checked, and attached to a document you signed.

---

Awesome Apps is an app developer in Sydney building iOS and Android apps for Australian businesses. Security and infrastructure work comes from Cloud Geeks. General information, not legal advice.