Hvad er webhook replay protection?

Webhook replay protection er en sikkerhedsmekanisme, der forhindrer, at en legitim webhook-anmodning kan kopieres og sendes igen (“replayed”) for at udløse de samme handlinger flere gange. Det gøres typisk ved at validere signatur, tidsstempel og en unik event-ID (nonce) og ved at afvise dubletter eller for gamle beskeder.

Hvad består webhook replay protection af?

Replay protection er sjældent én enkelt funktion. Det er et sæt kontroller, der tilsammen gør det svært eller umuligt at genbruge en tidligere, gyldig webhook til at manipulere dine systemer. I B2B-integrationer (CRM, marketing automation, billing, lead management) handler det især om at sikre dataintegritet og undgå utilsigtede forretningshændelser.

• Autentificering af afsender: Ofte via HMAC-signatur (f.eks. SHA-256) beregnet over payload + hemmelig nøgle, så du kan validere, at webhooken kommer fra den forventede tjeneste.
• Tidsstempel og “freshness”-vindue: Et krav om, at webhooken er modtaget inden for et kort tidsinterval (f.eks. 5 minutter). Ellers afvises den.
• Unik event-identifikator (event-id/nonce): En unik nøgle pr. webhook-event, som du gemmer og bruger til at afvise dubletter.
• Idempotens: Din modtagerlogik håndterer samme event flere gange uden at skabe dobbelt-effekter (f.eks. ingen dublette leads eller dobbelt fakturering).
• Persistens og logning: Du gemmer behandlingsstatus og nøglemetadata (event-id, timestamp, signature-hash) til audit, fejlsøgning og rate-limiting.

Hvordan fungerer webhook replay protection?

Når en webhook sendes fra en ekstern platform til din endpoint, forsøger en angriber (eller en fejl i netværk/integration) i praksis at få den samme besked behandlet flere gange. Replay protection bryder dette ved at gøre webhook-beskeden “engangsbrug” eller tidsbegrænset.

Et robust flow ser typisk sådan ud:

• 1) Verificér signatur: Du beregner selv signaturen ud fra den rå request body og en delt hemmelighed og sammenligner med signaturen i headeren. Fejler den, afvises webhooken.
• 2) Verificér tidsstempel: Du læser et timestamp fra header/payload og tjekker, at det ligger inden for et accepteret vindue. Dette gør “sen replay” ubrugelig.
• 3) Tjek event-id mod en “seen events”-database: Hvis event-id allerede er set (og evt. markeret som “processed”), afviser du eller returnerer et idempotent OK-svar uden at gentage handlinger.
• 4) Behandl eventen og gem status: Først når valideringerne er bestået, udfører du forretningslogikken (opret lead, opdater status, trig kampagne) og gemmer eventen som behandlet.

Det vigtige er rækkefølgen: du vil afvise så tidligt som muligt for at minimere belastning og risiko, og du vil designe processen, så den tåler retries (som er almindelige ved webhooks).

Hvorfor er webhook replay protection vigtigt for B2B-virksomheder?

I B2B er webhooks ofte en kritisk motor i din pipeline: de flytter data mellem systemer og udløser handlinger med direkte kommerciel effekt. Hvis en webhook kan genafspilles, kan konsekvensen være mere end “teknisk støj” — det kan blive til reelle tab eller compliance-problemer.

• Undgå dublette leads og forkerte salgsaktiviteter: En replay kan oprette samme lead flere gange, tildele forkerte ejere eller starte flere nurture-flows. Det kan forringe datakvaliteten og sænke conversion.
• Beskyt økonomiske transaktioner: Hvis webhooks bruges til betaling, abonnement eller ordrestatus, kan replay give dobbelt bogføring eller fejl i revenue recognition.
• Højere tillid til automation: Når du kan stole på, at events kun behandles én gang (eller idempotent), tør du automatisere mere og hurtigere.
• Bedre sikkerhed og governance: Replay protection er en del af en moden integrationssikkerhed (sammen med rate limiting, least privilege og audit logs).

For virksomheder, der arbejder målrettet med leadgenerering og systemintegration, bliver stabilitet og dataintegritet en konkurrenceparameter. Hvis du bygger en leadmotor eller integrerer berigede virksomhedsdata i dine flows, skal dine webhook-endpoints kunne tåle både retries og misbrug. Se f.eks. hvordan en struktureret tilgang til data og flows kan understøtte leadarbejdet via Cohertas leadmotor.

Hvordan bruges webhook replay protection i praksis?

I praksis afhænger implementeringen af, om du modtager webhooks fra en SaaS-platform (CRM, marketing automation, payments) eller om du selv udstiller webhooks som del af et API. Uanset scenarie bør du fokusere på både sikkerhed og drift.

Design dine endpoints til at tåle retries

De fleste webhook-afsendere gensender automatisk ved timeout eller 5xx-svar. Derfor skal du forvente dubletter og designe idempotent behandling. En god tommelfingerregel: “Samme event-id må aldrig kunne skabe to forskellige forretningsresultater.”

Gem event-id’er i et dedikeret “dedupe store”

Gem en unik nøgle (event-id eller en hash af payload + timestamp) i en database med TTL (time-to-live). TTL bør matche din risiko og dine integrationsmønstre, ofte 24–72 timer. Hvis du modtager samme nøgle igen, returnerer du 200 OK (eller 409) uden at udføre handlingen igen.

Brug et snævert tidsvindue og synkroniser ure

Tidsstempel-check fungerer kun, hvis dine servere har korrekt tid (NTP). Sæt et realistisk vindue (f.eks. 5 minutter) og log afvisninger, så du kan se, om en partner har driftproblemer.

Valider signatur på den rå request body

Mange fejl opstår, hvis man signer/verificerer en “parsed” version af JSON i stedet for den rå body. Sørg for at bruge præcis samme input som afsenderen forventer. Implementér også konstant-tids sammenligning for at reducere risikoen for timing-angreb.

Kobl replay protection til din forretningslogik (ikke kun security)

Replay protection handler ikke kun om at afvise angribere. Det handler også om at sikre, at dine egne flows ikke skaber dubletter, når du eksempelvis:

• skubber leads fra én kilde til dit CRM
• starter e-mailsekvenser i marketing automation
• synkroniserer firmadata og scoring

Hvis du arbejder med automatiseret leadhåndtering, kan det være relevant at tænke replay protection ind i hele datavejen—fra ideel kundeprofil til aktivering i kampagner. Du kan læse mere om at definere målretningen i Cohertas guide til ideel kundeprofil og om selve setup’et via sådan virker Coherta.

Fordele og ulemper

• Fordel: Færre dubletter og højere datakvalitet
  Du undgår gentagne oprettelser/opdateringer, hvilket giver renere CRM-data og mere pålidelige rapporter.
• Fordel: Bedre sikkerhed
  En opsnappet webhook er ikke nok i sig selv, fordi den enten udløber (timestamp) eller bliver afvist som dublet (event-id).
• Fordel: Mere robust drift
  Når du forventer retries og dubletter, reducerer du risikoen for fejl i automatisering og minimerer manuel oprydning.
• Ulempe: Ekstra kompleksitet
  Du skal håndtere lagring af event-id’er, TTL, logning og edge cases (f.eks. out-of-order events).
• Ulempe: Risiko for “false positives”
  For stramme tidsvinduer eller fejl i clock sync kan få legitime webhooks afvist. Det kræver monitorering og klare fallback-processer.

Typiske misforståelser

• “En signatur alene stopper replay.”
  Signaturen beviser autenticitet, men en angriber kan stadig gensende den samme gyldige request, hvis du ikke også bruger timestamp og/eller event-id deduplikering.
• “Hvis vi svarer 200 OK, kommer den ikke igen.”
  Afsendere kan retry ved netværksproblemer, timeouts eller hvis din 200-respons ikke når frem. Du skal stadig være idempotent.
• “Replay protection er kun relevant for betalinger.”
  I B2B er et “dobbelt lead” eller en forkert statusopdatering ofte dyrt i tid, pipeline-kvalitet og kundeoplevelse.
• “Vi kan bare filtrere dubletter i CRM.”
  Det er bedre at stoppe dubletter før de skaber sideeffekter (tildeling, tasks, e-mails, scoring). CRM-deduplication er sjældent nok alene.

FAQ

Er webhook replay protection det samme som idempotens?

Nej. Idempotens betyder, at din behandling tåler gentagne kald uden at skabe ekstra sideeffekter. Replay protection handler om at identificere og afvise/neutralisere genafspilninger, typisk via timestamp og event-id. De bør bruges sammen.

Hvad er den mest almindelige måde at implementere replay protection på?

En kombination af HMAC-signaturvalidering, timestamp-check (f.eks. max 5 minutter gammelt) og lagring af event-id’er i et dedupe store med TTL. Det dækker både autenticitet, “freshness” og dubletkontrol.

Hvad gør jeg, hvis webhook-udbyderen ikke sender event-id?

Så kan du danne en stabil nøgle selv, f.eks. en hash af den rå payload kombineret med et timestamp-headerfelt. Det er ikke lige så stærkt som et ægte event-id, men kan stadig reducere dubletter markant, især ved retries.

Skal jeg returnere 200 OK eller en fejl, når jeg ser en replay?

Det afhænger af udbyderen. I mange tilfælde er det bedst at returnere 200 OK ved dublet (idempotent “already processed”), så afsenderen ikke fortsætter med retries. Ved mistænkelig trafik (f.eks. ugyldig signatur) bør du returnere 401/403 og logge hændelsen.

Hvordan hænger replay protection sammen med integrationer til marketing automation?

Hvis et lead-event genafspilles, kan du utilsigtet starte flere flows, oprette dublette kontakter eller sende flere e-mails. Når du kobler leads til platforme som ActiveCampaign, er det ekstra vigtigt at sikre idempotente updates og dubletkontrol. Se mulighederne for datalevering i leads til ActiveCampaign.

Få styr på sikre integrationer, der ikke skaber dubletter i din pipeline

Hvis du vil bygge en mere robust lead- og dataautomatisering, hvor webhooks ikke skaber dubletter eller fejl i CRM og marketing automation, kan du med fordel tænke replay protection ind som en fast del af dit integrationsdesign.

Vil du se, hvordan du kan operationalisere firmadata og leadflows mere sikkert i praksis, kan du starte med at se hvordan Coherta virker eller dykke ned i Cohertas leadmotor for et samlet setup til målretning, data og aktivering.