For builders and no-code teams
You built an app. Verify you haven't exposed any data.
Today's tools let you stand up a working system in a week. They don't watch who gets to see whose data. That is exactly the gap we close before release.
01
What this problem really looks like
This is not attack theory. It is one query that should fail, and doesn't.
The app serves many clients from one database. The interface shows each of them only their own data, because that is how the query was written. But the database has no rule of its own to enforce it.
All it takes is a signed-in user querying the database directly, bypassing the interface. The key for that query is in the browser, because it has to be.
The query below was run by a user from account A, asking for account B's data. They should have got an empty response or a denial. They got the data.
tenant_a → GET /rest/v1/invoices?owner=eq.tenant_b
200 OK · 148 records · read policy: none
tenant_a → GET /rest/v1/invoices?owner=eq.tenant_b
200 OK · 0 records · policy: invoices_select_own
02
What we check
01
Data boundaries
Whether access rules exist on every table and cover read, insert, update and delete. Reads alone are not enough.
02
Authentication
Who can sign in, what they see after signing in, whether they can escalate their own privileges and whether signing out actually ends the session.
03
Secrets
Whether a key with full database access has ended up in the browser, the repository or the logs.
04
Files
Whether attachments have an access policy, whether URLs are predictable and whether someone else's file can be downloaded by swapping the ID.
05
Public surface
What the system shows without signing in: test routes, debug panels, old API versions, source files with comments.
06
Dependencies
Whether the libraries you use have known vulnerabilities and whether any of them reach somewhere they shouldn't.
03
How it works
- You submit the app and tell us what it does and whose data it holds.
- We agree the scope and what you share with us. Read-only by default.
- We check. We change nothing in your system.
- You get a list of release blockers, separated from things that can wait.
- Every blocker comes with a specific fix, not a generic tip.
- After the fix we run a retest and add the result to the report.
04
What not to expect
This is not a full penetration test
We check a specific, written scope. Everything outside it is listed in the report as untested, not left unsaid.
We won't say the app is secure
We will say what we checked, what we found, what could not be established and as of which date it holds. The rest is marketing.
Better to find out now than from a client
Tell us what you built and whose data it holds. We will reply with what can be verified and how long it will take.