Zo ziet een Launch Check-rapport eruit

Een Launch Check eindigt met een geschreven rapport: wat ik getest heb, wat ik vond, hoe ernstig elke bevinding is en hoe je het oplost. Hieronder wat erin staat, en één uitgewerkte voorbeeldbevinding.

Wat er in het rapport staat

  1. ManagementsamenvattingIn gewone taal: hoe je app ervoor staat, wat er op het spel staat en wat je eerst oplost.
  2. Scope en aanpakWat er getest is, hoe, en hoe het risico van elke bevinding wordt bepaald.
  3. BevindingenPer bevinding: het risico, waar het zit, wat er mis is, de impact, hoe je het reproduceert en hoe je het oplost.
  4. VervolgstappenWat je eerst oplost, de hertest zodra het is opgelost (inbegrepen), en uitleg of een kort gesprek als je ontwikkelaar vragen heeft over een oplossing.

Het rapport is digitaal ondertekend: iedereen kan controleren dat het echt is en niet is aangepast, via re-sync.nl/verify. Je ontvangt het via je beveiligde portaal.

Eén voorbeeldbevinding

Een fictieve app met fictieve data. Zo staat elke bevinding in het rapport beschreven.

HoogBroken Access Control (OWASP A01)Fictief voorbeeld

RLS-policy op factuurregels laat elke ingelogde gebruiker de regels van alle workspaces lezen

Beschrijving

De tabel invoices heeft RLS aan, en de policy beperkt het lezen netjes tot de eigen workspace van de gebruiker. De tabel invoice_lines heeft ook RLS aan, maar die policy controleert alleen of iemand is ingelogd. Elke ingelogde gebruiker kan daardoor de factuurregels (omschrijvingen, aantallen en bedragen) van de facturen van álle workspaces lezen, ook al blijven de facturen zelf afgeschermd.

Reproductie

Log in als gebruiker A (workspace X). Vraag invoice_lines op via de Supabase REST-API, met de publieke anon-sleutel en de sessietoken van gebruiker A, zonder filter. Het antwoord bevat ook regels van facturen van workspace Y.

Aanbeveling

Vervang de policy op invoice_lines door een die kijkt naar de workspace van de bijbehorende factuur. Verwijder daarbij de oude policy: Postgres combineert permissive policies met OR, dus alleen een strengere toevoegen verandert niets.

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()
  ));

Hierbij geeft auth_workspace_id() de workspace van de ingelogde gebruiker terug. Voeg daarna een geautomatiseerde test toe die als gebruiker van een tweede workspace queryt en nul rijen verwacht.

Nu al een compleet rapport zien? Het volledige voorbeeldrapport voor een grotere, fictieve opdrachtgever heeft dezelfde opbouw.

Dit rapport voor jouw app?

Vaste prijs, hertest inbegrepen, direct online te boeken.

Boek een Launch Check →