What a Launch Check report looks like

A Launch Check ends with a written report: what I tested, what I found, how serious each finding is and how to fix it. Below: what's in it, and one worked example finding.

What's in the report

  1. Management summaryIn plain language: how your app holds up, what's at risk and what to fix first.
  2. Scope and methodWhat was tested, how, and how each finding's risk is rated.
  3. FindingsPer finding: the risk, where it is, what's wrong, the impact, how to reproduce it and how to fix it.
  4. Next stepsWhat to fix first, the retest once it's fixed (included), and a clarification or short call if your developer has questions about a fix.

The report is digitally signed: anyone can check that it is genuine and unaltered at re-sync.nl/verify. You receive it through your secure portal.

One example finding

A fictional app with fictional data. This is how every finding in the report is written up.

HighBroken Access Control (OWASP A01)Fictional example

RLS policy on invoice lines lets any logged-in user read every workspace's line items

Description

The invoices table has RLS enabled, and its policy correctly limits reads to the user's own workspace. The invoice_lines table has RLS enabled too, but its policy only checks that the user is logged in. Any authenticated user can therefore read the line items (descriptions, quantities and amounts) of every workspace's invoices, even though the invoices themselves stay hidden.

Reproduction

Log in as user A (workspace X). Query invoice_lines through the Supabase REST API with the public anon key and user A's session token, without a filter. The response also contains line items of invoices that belong to workspace Y.

Recommendation

Replace the policy on invoice_lines with one that checks the workspace of the parent invoice. Drop the old policy while you're at it: Postgres combines permissive policies with OR, so only adding a stricter one changes nothing.

drop policy "authenticated can read" on invoice_lines;
create policy "read lines of own workspace" on invoice_lines
  for select to authenticated
  using (exists (
    select 1 from invoices i
    where i.id = invoice_lines.invoice_id
      and i.workspace_id = auth_workspace_id()
  ));

Here auth_workspace_id() returns the logged-in user's workspace. Then add an automated test that queries as a user of a second workspace and expects zero rows.

Want to see a complete report right now? The full sample pentest report for a larger, fictional client has the same structure.

Want this report for your app?

Fixed price, retest included, bookable online.

Book a Launch Check →