Cases · App check
Payment and access review of an app on Supabase and Stripe
A real, publicly available product, not a sample. The owners were told privately first, and this page names neither the app nor any single finding while the findings are open.
October 2026: owners contacted. The full report and patches follow once they reply.
The case
What was reviewed
A public web app on Supabase and Stripe. The review covered who may read and change what in the database, file storage and server functions; payments and refunds; roles and access.
What makes it hard
Here the money has to agree in two places: what was paid and what the app records.
How it was checked
Each finding was reproduced on the owners' current code, and each patched finding was checked again with its patch; where a point rests on the code alone, the report says so. 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
17 findings: 2 high, 5 medium, 10 low. The 19 proposed patches fix 14 in full and 2 in part. The owners' own tests pass before and after; one of them is updated to a patched rule. One finding is left to the owners as a question, because its fix depends on a product decision. The owners were contacted privately 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 | High | Medium | Low | Total |
|---|---|---|---|---|
| Payments | 2 | 1 | 3 | 6 |
| Data and files | — | 1 | 3 | 4 |
| Roles and access | — | 3 | 3 | 6 |
| Other | — | — | 1 | 1 |
| Total | 2 | 5 | 10 | 17 |
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:
- Paid orders that can get stuck
- Gaps in who may change what
- Payment steps without a safety net
- Features that silently do nothing
- Access wider than promised
What goes to the owners
- A report with every finding: what happened, what should have happened and why, and where it is in the code.
- 19 patches on top of their current commit, with the order, the dependencies and the deploy order.
- 5 questions on the points only the owners can decide, and one suggestion that is not counted as a finding.
- Known limitations of the patches themselves: mostly a failure at one exact moment or a rare state.
- What the review did not cover: some screens and some payment paths.
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.