A REAL FINDING, WALKED THROUGH
See how we confirm what is actually wrong before we touch anything.
This real finding follows one account and billing problem from the behavior someone could trigger to the code that confirmed it and the direction that would fix it.
Identifying details have been removed. This page follows one finding to show how we work before any fix is agreed.
Someone could change a customer’s account balance without proving the account was theirs.
A backend function could change a customer’s account balance with elevated database privileges. Instead of verifying who was logged in, it trusted the account ID supplied in the request.
Because the function was reachable through public API roles, the same pattern could let a caller credit their own account or modify records that did not belong to them.
What was found
A privileged backend path accepted an account ID from the caller and changed account state without tying the action back to the logged-in user. The issue was not limited to one function. The same trust pattern appeared in related functions that could modify or delete another customer’s records.
Why it matters
A customer should only receive credits through the verified payment flow. In this case, the backend trusted an ID supplied by the caller, so it could not reliably tell whether the caller owned the account being modified. That turns a small-looking permission mistake into a billing, data integrity, and trust problem.
-- SECURITY DEFINER: elevated database privileges CREATE FUNCTION credit_account_fn(p_account_id uuid, p_type text, p_amount int) -- account_id supplied by caller -- no ownership check against logged-in user GRANT ALL ON FUNCTION credit_account_fn TO anon;
This shortened evidence shows the file, privilege, caller input, missing ownership check, and public grant that confirmed the problem.
Recommended direction
Close the function to public callers and only allow the verified backend or payment service to invoke it. For any function that must stay reachable from the client, add an explicit ownership check tied to the logged-in user before changing account state.
What happens next
Once the cause is confirmed, the work gets a clear finish line.
We tell you in plain words what the finished result will do.
If the problem can be handled as one repair, the job costs $99 and we complete it within three business days once access works. Other work is quoted after we review the code.
We make the change and show you the result working.
If it does not work as agreed, you do not pay.
What someone could actually do, backed by the app and code.
The route, file, function, or behaviour connected to the issue.
What direction to take and whether it is likely to be a narrow fix or a broader change.
Tell us what has become difficult in your app.
On a free 20-minute call, explain what the app does, who relies on it, and what should work. New clients can pay $99 once for one agreed blocker. We fix it within three business days once access works, and you pay after seeing it work.