SAMPLE FINDING EXCERPT
See how one confirmed finding appears in the Audit Report.
This excerpt shows how the Audit Report explains one confirmed issue: what happened, why it matters, and what direction to take next.
Some details are intentionally shortened or redacted. The paid Audit Report includes the full finding set, Priority Action Plan, and recommended next steps.
A public caller could trigger a privileged backend function by supplying an account ID.
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 is a shortened preview. The paid Audit Report includes related functions, affected call paths, and developer-facing confirmation notes.
Recommended direction preview
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 the final Audit Report adds
Exact request shape, affected route family, and how the behaviour was confirmed.
Other places where the same trust pattern appears so the recommended action is not applied too narrowly.
What deserves attention first, what can wait, and which actions reduce the most risk fastest.
Recommended direction your developer can turn into a fix plan.
What someone could actually do, not just a generic warning.
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 deeper review.
Want this level of review for your app?
The Audit reviews your app through the Beyond the Demo Framework, confirms the important findings, and gives you a Priority Action Plan your developer can act on.