Webhooks og udgående integrationer

Et webhook sender besked fra jeres produkt til en adresse, som kunden selv har valgt, hver gang der sker noget, og dermed forlader kundens data produktet uden at nogen trykker på en knap. Svaret på, om webhooks og andre udgående forbindelser hører med i pentesten, er ja, og det hviler på to forhold. Data skal kun nå den modtager, kunden har valgt. Og den adresse, kunden indtaster, må ikke kunne få produktet til at gøre noget, det ikke er bygget til.

Det API, som kundernes systemer kalder ind i, er en anden retning og et andet emne. Her går trafikken den anden vej, fra jer og ud. → Produktets API

Data, der forlader produktet af sig selv

En almindelig integration starter hos kunden: kundens system spørger, og produktet svarer. Et webhook starter hos jer. Produktet beslutter, hvornår der sendes, hvad der sendes, og hvortil. Det gør jer til afsender af kundens data, og det giver kunderne en række spørgsmål, de ikke stiller til en almindelig integration.

Udgående forbindelser er ikke kun webhooks. Det kan også være planlagte eksporter til kundens lager, synkronisering til et andet system, mails med rapporter eller beskeder til en chattjeneste. Alle har det tilfælles, at data bevæger sig ud af produktet efter regler, som kunden har sat op, og som produktet udfører.

Hvad kunderne spørger om

Kundens sikkerhedsansvarlige vil måske vide:

Hvem kan sætte det op · kræver det en administratorrolle at oprette eller ændre et webhook?
Hvad der sendes · hele poster, eller kun en besked om, at noget er ændret?
Hvordan modtageren kan stole på det · kan kundens system se, at beskeden faktisk kommer fra jer?
Hvad der sker ved fejl · bliver data sendt igen, og hvor længe ligger det i kø?
Hvad der logges · kan kunden se, hvad der er sendt, og hvortil?

Det første spørgsmål er vigtigt. Hvis en almindelig bruger kan ændre adressen på et webhook, kan den bruger sende kundens data et andet sted hen. Det er en rollefejl, men den viser sig i den udgående trafik. → Roller og rettigheder i produktet

Hvad testen afprøver

Testen ser på de udgående forbindelser som en funktion i produktet med egne grænser:

Opsætningen · kan kun de rette roller oprette, ændre og slette udgående forbindelser?
Indholdet · indeholder beskederne kun data fra den kunde, forbindelsen tilhører? → Multi-tenant: test af adskillelsen mellem kunderne
Afsenderen · kan modtageren kontrollere, at beskeden kommer fra jer og ikke er ændret undervejs?
Adressen · kan den adresse, kunden indtaster, bruges til andet end at sende beskeder til kundens eget system?
Fejlbeskeder · afslører produktet noget om sig selv, når en levering mislykkes?

Det er beskrevet på begrebsniveau, så I kan skrive det i omfanget. Testeren har brug for testlejere med rettighed til at oprette forbindelser, og for en modtager, testeren selv styrer.

Adressen, som kunden selv indtaster

Når en kunde skriver en adresse ind, og produktet derefter kontakter den, får kunden en vis indflydelse på, hvad jeres servere gør. OWASP nævner webhooks blandt de funktioner, hvor et API henter eller sender noget til en adresse, som brugeren har angivet, og hvor manglende kontrol af adressen kan få produktet til at sende forespørgsler til steder, der ikke var tilsigtet, også bag en firewall.

For jer er pointen, at webhook-funktionen er en del af jeres infrastruktur, ikke kun af brugerfladen. Det er derfor relevant at aftale, at testen ser på, hvad produktet kan nå, når det sender. Hvis infrastrukturen bag produktet ikke er med i testen, er det et af de steder, hvor grænsen mellem applikation og drift bliver tydelig. → Infrastrukturen bag produktet

Andre udgående forbindelser

Eksporter, synkronisering og mails rejser de samme spørgsmål i en anden form. En planlagt eksport, der skriver til kundens lager, bruger adgangsoplysninger, kunden har givet jer. Hvor de opbevares, og hvem der kan se dem, er et af de spørgsmål, kunderne stiller. En mail med en rapport kan ende i en indbakke, der ikke længere tilhører kunden.

Nogle udgående forbindelser er bygget til en enkelt stor kunde og senere gjort tilgængelige for andre. De kan have en anden opsætning end resten, fx faste adgangsoplysninger eller en modtager, der er skrevet direkte ind i koden. Netop fordi de opstod som en tilpasning, er de ikke altid med på den liste, udviklingsteamet har over integrationer.

Tag med i omfanget, hvilke udgående forbindelser produktet har, og hvilke der er med i testen. Hvis listen er lang, så prioritér dem, der sender mest data, og dem, hvor kunden selv indtaster modtageren.

Når fundet ligger i jeres udgående trafik

Fund i webhooks og eksporter er lette at forklare for kunderne, fordi de handler om, hvor data kan ende. Det er også fund, hvor kunderne vil spørge, om noget faktisk er sendt forkert. Svaret kræver, at I kan se, hvad der er sendt og hvortil. Hvis jeres logning ikke kan svare på det, er det et fund i sig selv. → Logning og revisionsspor i produktet

Overvej også, om kunder skal have besked, hvis fundet betyder, at data kan være sendt til en forkert modtager. Det afhænger af, hvad jeres logs viser, og af jeres kontrakter.

Husk, at en rettelse kan ændre, hvordan beskederne ser ud, eller kræve, at kunderne kontrollerer afsenderen på en ny måde. Så skal kundernes egne systemer tilpasses, og det kræver varsel.

Det skal I lade være med

Holde webhooks uden for omfanget, fordi de er små · de sender kundedata ud af produktet.
Lade alle roller ændre modtageradressen · så kan en bruger flytte kundens data.
Sende hele poster, når en besked om ændringen er nok · mindre data ud betyder mindre at miste.
Gemme kundernes adgangsoplysninger til eksport uden at kunne forklare hvor · kunderne spørger.
Glemme de andre udgående forbindelser · eksporter og mails hører med.
Ændre beskedformatet uden varsel · kundernes systemer stopper.

Hvad kan og ikke kan konkluderes

En test af de udgående forbindelser viser, om rollerne, indholdet, afsenderen og adresserne holdt de aftalte grænser i den testede version. Den siger intet om, hvordan kundens eget system modtager og opbevarer beskederne. Det er kundens del. → Kundernes eget ansvar

Tjekliste til de udgående forbindelser

☐ Er alle udgående forbindelser listet, og står de relevante i omfanget?
☐ Er det kun de rette roller, der kan oprette og ændre dem?
☐ Har testeren en modtager, testeren selv styrer?
☐ Er det afprøvet, at beskederne kun indeholder den rette kundes data?
☐ Kan modtageren kontrollere afsenderen?
☐ Kan I se i logs, hvad der er sendt og hvortil?

Kilder

OWASP API Security Top 10 2023: Server Side Request Forgery: risikoen ved funktioner, der kontakter en adresse angivet af brugeren, med webhooks som eksempel.

Senest gennemgået: oktober 2026.