Is CueBill Safe? The Truth About App Keys, Encryption & Your Members' Data
A recent comparison page claimed CueBill 'exposes database credentials' in its app. Here's the straight, technical answer on publishable keys, Row-Level Security and how your club's data is actually protected.
CueBill Team ·
If you run your club on CueBill, you may have seen a competitor comparison page claiming that CueBill “exposes Supabase database credentials and Google API keys” in its app bundle, and that this puts your members’ phone numbers and khata balances at risk.
You deserve a straight, technical answer — not marketing. So here it is, with the actual facts about how the app is built. Your data is safe, and we’ll show you exactly why.
The short answer
Yes — like every modern app, CueBill’s app contains a Supabase key and a Firebase configuration key. And that is completely normal, expected, and safe. These are publishable keys. They are designed to be public. They are not “database credentials,” and on their own they cannot read a single row of your club’s data.
The entire accusation rests on blurring one critical distinction: a publishable key (meant for the client) versus a secret key (which never leaves our servers). Once you understand that difference, the claim falls apart.
What’s actually in a modern app — and why
Almost every web and mobile app built in the last five years — including apps built on Supabase, Firebase, Stripe, Google Maps and dozens of other platforms — ships a publishable key inside the app. This is by design. The platform vendors document it explicitly.
Think of a publishable key like the public street address of a bank. Anyone can read it off the app, just like anyone can look up a bank’s address. Knowing the address does not let you walk into the vault. It simply tells the app which backend to talk to.
- Supabase’s publishable / “anon” key identifies the project and lets the app ask for data. What it’s actually allowed to see is decided by the server — see the next section.
- Google’s Firebase config key (the
AIza…value) is, in Google’s own words, safe to include in client code. It identifies the Firebase project; it is not a secret. - Google Sign-In client IDs are public identifiers by design — the matching secret stays on the server.
None of these are “credentials to your database.” Calling them that is like calling a bank’s public address a “master key to the vault.”
The real lock: Row-Level Security
Here is what the comparison page conveniently leaves out — the part that actually protects your data.
Every table in CueBill is protected by Row-Level Security (RLS), enforced by the PostgreSQL database itself on our servers. We ship RLS on all data tables, with 64 access policies that scope every single request to the club that made it, using server-side membership and role checks.
In plain terms: even if someone reads the publishable key straight out of the app, and sends a request with it, the database will only ever return rows that belong to their own authenticated club. A request cannot reach across to another club’s customers, credit balances, or bills. The key opens the front door of the building — but every room has its own lock, keyed to you and only you.
A publishable key without a valid, logged-in session that passes Row-Level Security is inert. It returns nothing sensitive. That is the whole point of the design.
The admin key never touches the app
Supabase does have a powerful “god-mode” key — the service role key — that bypasses Row-Level Security. If that ever shipped in an app, it would be a genuine problem.
It does not. In CueBill, the service role key exists only inside our server-side functions, read from a protected server environment variable. It appears zero times in the app that runs on your phone. Privileged operations — subscription checks, push notifications, billing webhooks — run on the server, never as raw commands from the client.
Your session lives in the phone’s secure hardware
We go further than the baseline:
- Your login session is stored in the device’s hardware-backed secure store (the iOS Keychain / Android Keystore), not in plain, readable storage.
- Sign-in uses the PKCE flow — the modern standard designed to prevent token interception.
- Sensitive actions are gated by server-side roles and permissions, not by hiding buttons in the UI.
So what does “extracting keys from the APK” actually get an attacker?
Nothing they couldn’t already see, and nothing useful. Reading a publishable key out of an Android app is the same as opening the developer tools on any website and seeing the public keys the site uses — it’s routine and harmless. Without a valid login and a matching Row-Level Security policy, that key cannot read your members’ data. Full stop.
About that comparison page
We’ll be measured here, because facts do the work.
The page making this accusation is itself built on Supabase — its own website ships a Supabase project URL and a publishable key to every visitor’s browser, exactly like ours does. We’re not saying their app is insecure for it. It isn’t — and neither is ours. That’s precisely the point: a publishable key in the client is how the platform is designed to work, for them and for us.
Which means the “exposed keys = data leak” claim doesn’t survive five minutes of contact with how the technology actually works. Anyone describing a publishable key as a “data breach” is either misunderstanding the platform they themselves are using — or counting on you not to check.
How to judge any club app’s security (ours included)
Don’t take anyone’s word — including a comparison page’s. Ask these questions of any vendor:
- Is Row-Level Security enabled on every table? (For CueBill: yes — on all data tables, 64 policies.)
- Does the admin/service key ever ship in the app? (For CueBill: no — server-side only.)
- Where is my login session stored? (For CueBill: the phone’s hardware keystore.)
- Do privileged actions run on the server, or as raw client commands? (For CueBill: server-side functions.)
A “publishable key is visible in the app” is not on that list, because it isn’t a vulnerability — it’s the design.
The bottom line
CueBill is built the way professional, production software is built: publishable keys in the client, real secrets on the server, and Row-Level Security enforcing that every club only ever sees its own data. Your members’ phone numbers and khata balances are protected by the database itself, not by hoping nobody opens the app file.
If a comparison page has to misrepresent how app keys work to make a point, that tells you more about the comparison than about CueBill.
Want to see it for yourself? Start a 14-day free trial — no credit card — and run your real club on it. Or read our honest software comparisons to see how we stack up when the facts are on the table.