What we found, anonymised by sector.

Lending: full bank account numbers, readable by anyone

A lending product stored a table of full bank account numbers, readable by anyone holding the app's public API key. The key is meant to be public; the table behind it had no access rule. Nothing in the app hinted at the exposure, because the app worked perfectly for every legitimate user.

The fix was row-level security scoped so each record was reachable only by the account that owned it, plus a review of every other table for the same gap. Reachable in one unauthenticated request before; closed after.

Health: patient access codes and payment codes exposed

A health app exposed patient access codes and payment codes to anyone with its public key, the same missing-access-rule pattern behind a different kind of sensitive data. Private in intent, public in fact, and completely invisible from the front end.

The fix locked down the affected tables with correct policies for both reads and writes, and we re-tested from the outside to confirm the codes were no longer reachable.

Education: stored Google auth tokens, readable by strangers

An education platform kept its users' stored Google authentication tokens in a table readable with the public key. A token like that is enough to access the user's account elsewhere, so the exposure reached beyond the app itself.

The fix removed the tokens from any client-reachable path and enforced access rules on the table, closing both the direct exposure and the wider risk to users' other accounts.

Commerce: writable orders, payments and transactions

In several audited apps, tables named orders, payments and transactions accepted writes from unauthenticated strangers. An outsider could insert a forged record the app would treat as real. In one app, a table named security_events, the audit log meant to record suspicious activity, was itself writable by anyone, so an attacker could overwrite the record of their own actions.

The fix was write policies that restricted inserts and updates to authorised accounts, and locking the audit log so it could be written only by the server.

SaaS: privileged functions anyone could call

One app left database functions named generate_license_key and generate_transfer_token callable with the public key. A stranger could call them directly and have the database mint a valid licence or transfer token for them, no account required.

The fix moved these behind a server-side authorisation check so only the application, acting for an authorised user, could invoke them.

The pattern, and the exception

Across 1,236 apps we have scanned and 12,205 findings we have logged, the story repeats: an app that works, a public key that is meant to be shared, and a missing rule behind it. Twenty-one apps came back clean. It is possible to build securely on these tools; it just does not happen by default. An audit is how you find out which kind yours is.