Cases · App check
Access and payment review of a live Supabase and Stripe app
A real, live app, not a sample. Everything went to the owners privately first, and this page names neither the app nor any single finding while the findings are open.
October 2026: sent to the owners. Patches proposed, not applied yet.
The case
What was reviewed
A live web app on Supabase and Stripe. The review covered who may read and change what in the database, file storage and server functions; purchase and refunds; and the related screens.
What makes it hard
The app already has rules for who may read and change what, and they have to hold for every role and on every path, not only the usual one: the screens, the database and the server functions each decide part of it.
How it was checked
Each finding was reproduced on the owners' current code, and each patched finding was checked again with its fix. A few findings and fixes were checked against the code only, and the report marks them as such. Each finding says what happened, what should have happened and where that expectation comes from: the app's own screens, texts, code and documentation, or common practice.
Result
63 findings: 1 critical, 9 high, 16 medium, 37 low. The 58 proposed patches fix 49 in full and 8 in part, and the owners' own tests give the same results before and after, apart from the tests that two patches update to the new rules. Five findings are left to the owners, because their fix needs a decision only they can make; one was left unchanged on purpose, with the reason. Reported privately to the owners in October 2026. If the owners agree once the fixes are live, this page will name the project and describe the fixed findings.
Findings by area
| Area | Critical | High | Medium | Low | Total |
|---|---|---|---|---|---|
| Payments | 1 | 3 | 4 | 6 | 14 |
| Private data and files | — | 3 | 4 | 7 | 14 |
| Roles and access | — | 3 | 2 | 12 | 17 |
| Other business rules | — | — | 5 | 9 | 14 |
| Screens | — | — | 1 | 3 | 4 |
| Total | 1 | 9 | 16 | 37 | 63 |
Severity follows the consequence and how likely it is. Worth fixing here means critical, high or medium: in a polished app with real users, a medium finding can still reach them.
What kinds of defects
Most findings fall into a few patterns that are common in apps of this kind:
- Payment state that goes wrong
- Gaps in who may change what
- Business rules not enforced
- Private files shared too widely
- Personal data open wider than the screens suggest
- Features that silently do nothing
What the owners received
- A report with every finding: what happened, what should have happened and why, and where it is in the code.
- 58 patches on top of their current commit, with the order and the dependencies between them.
- 15 questions on the points only the owners can decide: their live data, their settings, their product choices.
- Five known limitations of the patches themselves. All arise only in rare conditions, and none of them loses money.
- What the review did not cover: the hosted payment page and email delivery, disputes, some paths and some screens.
Not a client job: the app was reviewed on my own initiative from its public code, without testing against the live site.
What a finding looks like
The findings of this app stay private while they are open. This is the same format, from the report on a sample shop.
Open the sample report (PDF)Any signed-in account can open any guest's order by its number
- AS RECEIVED
- The order page opens: name, street, city, email, phone, what was bought.
- AFTER THE FIX
- "We couldn't open this order."FIXED
- TEST
- A stranger's account asks for a guest's order. Failed before the fix, passes after.
Service
The same review for your app
You send the code or invite me read-only, not your passwords. Every finding comes with what happened, what should have happened and where it is in the code.