Din Slack-kanal pingar. Någon reagerar. Ett ärende skapas. Sedan inser du att larmet inte var på riktigt. Det var en förfalskad webhook, och nu städar du bort brus (eller värre) i stället för att göra faktiskt jobb.
Det här är typen av problem som drabbar Ops-ansvariga och SecOps-team först, men det hamnar också på skrivbordet hos en stressad marknadschef som kör “Slack-first”-processer. Verifiering av Slack-webhooks stoppar falska förfrågningar innan de skapar Slack-meddelanden eller triggar Gmail-utskick.
Det här arbetsflödet ger dig en praktisk grind: verifiera Slack-signaturen, släpp igenom korrekt formaterade payloads och stoppa resten direkt. Du får se hur det fungerar, vad du behöver och var du kopplar in det i dina nuvarande automationer.
Så fungerar den här automationen
Se hur detta löser problemet:
n8n Workflow Template: Slack + Gmail: stoppa spoofade webhooks i tid
flowchart LR
subgraph sg0["Execute Workflow Flow"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Make Slack Verif Token"]
n1@{ icon: "mdi:cog", form: "rounded", label: "Encode Secret String", pos: "b", h: 48 }
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "IF", pos: "b", h: 48 }
n3@{ icon: "mdi:location-exit", form: "rounded", label: "Stop and Error", pos: "b", h: 48 }
n4@{ icon: "mdi:play-circle", form: "rounded", label: "Execute Workflow Trigger", pos: "b", h: 48 }
n5@{ icon: "mdi:swap-vertical", form: "rounded", label: "Set Verified to True", pos: "b", h: 48 }
n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge"]
n2 --> n5
n2 --> n3
n1 --> n2
n5 --> n6
n0 --> n1
n4 --> n0
n4 --> n6
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n4 trigger
class n2 decision
class n0 code
classDef customIcon fill:none,stroke:none
class n0,n6 customIcon
Utmaningen: förfalskade Slack-webhooks triggar verkliga åtgärder
Slack-webhooks är smidiga, så team kopplar in dem i allt. Kontaktformulär skickar leads till Slack. Övervakningsverktyg postar larm. Interna appar triggar arbetsflöden. Haken är att “en förfrågan träffade min webhook-URL” inte betyder att den kom från Slack. Om du inte verifierar signaturer kan vem som helst som hittar eller gissar den endpointen skicka payloads som ser tillräckligt legitima ut för att trigga nedströms åtgärder, inklusive Gmail-notiser och auto-triage-flöden. Och helt ärligt är det värsta den tvekan det skapar. Folk slutar lita på larm.
Friktionen växer. Här är var det faller isär.
- Du slutar med att reagera på falska larm i Slack, vilket kan bränna ungefär en timme i veckan på utredning och att backa bandet.
- En förfalskad payload kan i tysthet trigga ett Gmail-mejl från din automation, så “skadan” är inte bara brus, det är utgående kommunikation du inte avsåg.
- När folk bränt sig några gånger börjar de ignorera notiser, och då tar det längre tid att fånga de verkliga incidenterna.
- Enkla webhook-lyssnare kan inte skilja “riktig Slack” från “slumpmässiga internet”, så din workflow-logik jobbar med opålitlig input.
Lösningen: verifiera Slack-signaturer innan Slack eller Gmail körs
Det här n8n-subarbetsflödet fungerar som en dörrvakt för alla automationer som tar emot Slack webhook-förfrågningar. Du matar in den råa förfrågan du fick från din Slack webhook-trigger, och den bygger upp exakt den “signature base string” som Slack förväntar sig för verifiering. Därefter använder den din Slack Signing Secret för att generera en HMAC-signatur och jämför den signaturen med vad Slack skickade i request headers. Om den matchar markerar arbetsflödet förfrågan som verifierad och skickar payloaden vidare så att resten av din automation tryggt kan posta till Slack, mejla via Gmail eller skapa ärenden. Om den inte matchar stoppar den direkt med ett fel, vilket betyder att inget nedströms ska köras om du inte uttryckligen väljer att ignorera fel.
Arbetsflödet startar när huvudflödet skickar in den mottagna Slack-förfrågan. Det genererar och kontrollerar en signatur med Slack Signing Secret. Efter det returnerar det antingen en enkel verified_signature: true plus den ursprungliga payloaden, eller så avbryter det körningen så att du kan hantera det som ett attackförsök.
Vad som förändras: före vs. efter
| Det här eliminerar | Effekten du kommer att se |
|---|---|
|
|
Praktisk effekt i verkligheten
Säg att du har 3 Slack-drivna automationer: en som postar ett larm, en som öppnar ett ärende och en som skickar en Gmail-notis till en on-call-adress. När en förfalskad förfrågan slinker igenom kanske du lägger cirka 30 minuter på att bekräfta att den är falsk och rulla tillbaka bieffekterna, och det kan hända några gånger i veckan. Med den här signaturkontrollen framför blir “arbetet” en snabb misslyckad exekvering som du kan logga och ignorera. Tidskostnaden sjunker till nära noll, och Gmail-steget körs aldrig.
Krav
- n8n-instans (testa n8n Cloud gratis)
- Självhosting om du föredrar det (Hostinger fungerar bra)
- Slack-app för att komma åt din Signing Secret.
- Slack webhook-trigger i ditt huvudflöde för att ta emot förfrågan först.
- Slack Signing Secret (hämta den i din Slack-apps dashboard under General Information).
Kunskapsnivå: Medel. Du kopierar en hemlighet, skickar vidare rå request-data och placerar ett subarbetsflöde direkt efter din webhook.
Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).
Flödet i arbetsflödet
En körning av subarbetsflödet triggas av inkommande Slack-förfrågan. Ditt huvudflöde tar emot Slack webhook-anropet och skickar sedan direkt headers och den råa body:n till detta subarbetsflöde för validering.
Arbetsflödet bygger upp Slacks signature base string på nytt. Det kombinerar Slack-timestampen och den råa payloaden i exakt det format Slack förväntar sig, inklusive några kodnings-edge cases som annars kan skapa “falska negativa” resultat.
En HMAC-signatur genereras och jämförs. Med Slack Signing Secret skapar arbetsflödet den förväntade signaturen och kontrollerar den mot signaturen som Slack skickade. Om de matchar behandlas förfrågan som autentisk.
Verifierade payloads fortsätter, overifierade payloads stoppas. En godkänd kontroll returnerar verified_signature: true och slår ihop den med originaldatan så att dina nästa noder (Slack-postning, Gmail, ärendehantering, RSS-berikning, HTTP-anrop) tryggt kan fortsätta. En misslyckad kontroll kastar ett fel, vilket hindrar att känsliga åtgärder utförs.
Du kan enkelt ändra vad som händer vid fel så att det passar din process, till exempel logga till en säkerhetskanal eller spara payloaden för granskning. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera triggern för Execute Workflow
Ställ in startpunkten för subarbetsflödet så att den här valideringen kan anropas från ett överordnat arbetsflöde.
- Lägg till noden Subflow Trigger Start som trigger för det här arbetsflödet.
- Lämna standardinställningarna som de är; den här noden kräver inga autentiseringsuppgifter.
- Koppla triggern så att Subflow Trigger Start skickar utdata till både Build Slack Signature Base och Combine Payloads parallellt.
Tips: Parallell körning krävs här så att den råa payloaden finns tillgänglig för sammanslagning samtidigt som signaturen beräknas.
Steg 2: Sätt upp konstruktion av signaturbas
Bygg den exakta Slack-signaturbassträngen från headers och body, i enlighet med Slacks kodningsregler.
- Lägg till noden Build Slack Signature Base och klistra in den tillhandahållna JavaScript-koden i Code.
- Bekräfta att koden läser tidsstämpeln från
requestJson.headers["x-slack-request-timestamp"]och signaturen frånrequestJson.headers["x-slack-signature"]. - Verifiera att utdatafälten innehåller
sigBaseStringochrequestSignatureenligt koden.
⚠️ Vanlig fallgrop: Slack förväntar sig URL-kodad formulärdata med specifika ersättningar. Ändra inte replaceAll-reglerna, annars misslyckas signaturen.
Steg 3: Koda och validera signaturen
Generera HMAC-signaturen och jämför den med signaturen som Slack tillhandahåller.
- Lägg till HMAC Signature Encode och ställ in Type till
SHA256. - Ställ in Action till
hmacoch Value till{{ $json.sigBaseString }}. - Ställ in Data Property Name till
candidateSignature. - Lägg till Signature Match Check och konfigurera strängvillkoret: Value 1 till
{{ $json.requestSignature }}och Value 2 tillv0={{ $json.candidateSignature }}.
⚠️ Vanlig fallgrop: Jämförelsen måste inkludera prefixet v0= i Signature Match Check, annars misslyckas valideringen alltid.
Steg 4: Konfigurera utdata och sammanslagning av payload
Markera giltiga signaturer och kombinera valideringsresultatet med den ursprungliga payloaden.
- Lägg till Mark Signature Valid på true-grenen från Signature Match Check.
- I Mark Signature Valid, ställ in Include till
noneoch lägg till ett booleskt fält med namnetsignature_verified. - Lägg till Combine Payloads och ställ in Mode till
combineoch Combination Mode tillmergeByPosition. - Koppla Subflow Trigger Start till Combine Payloads (input 1) och Mark Signature Valid till Combine Payloads (input 2).
Steg 5: Lägg till felhantering
Stoppa arbetsflödet när signaturen inte matchar.
- Koppla false-grenen från Signature Match Check till Abort With Error.
- Ställ in Error Message till
Could not verify Slack Webhook signaturei Abort With Error.
Steg 6: Testa och aktivera ert arbetsflöde
Verifiera att signaturverifieringen fungerar och aktivera för produktion.
- Använd Execute Workflow från ett överordnat arbetsflöde för att skicka in en exempel-payload för en Slack-begäran till Subflow Trigger Start.
- Vid lyckad körning ska flödet passera genom Signature Match Check till Mark Signature Valid och skicka ut sammanslagen data från Combine Payloads med
signature_verified. - Vid misslyckade signaturkontroller ska flödet stoppa vid Abort With Error med det konfigurerade meddelandet.
- När allt är verifierat, ställ in arbetsflödets status till Active för produktion.
Se upp med
- Slack-hemligheter och appinställningar roteras. Om verifieringen plötsligt misslyckas, bekräfta Signing Secret i din Slack-apps dashboard (General Information) och uppdatera den sedan i n8n.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströms noder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera outputs för alltid.
Vanliga frågor
Cirka 30 minuter om din Slack-app redan är konfigurerad.
Ja, men du vill ha någon som är bekväm med att kopiera headers och hemligheter. Ingen kodning krävs om du följer implementationsguiden noggrant.
Ja. n8n har ett gratis alternativ för självhosting och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med eventuella Slack-relaterade kostnader (oftast 0 USD om du inte har en betald Slack-plan av andra skäl).
Två alternativ: n8n Cloud (managed, enklast att komma igång) eller självhosting på en VPS. För självhosting är Hostinger VPS prisvärd och hanterar n8n bra. Självhosting ger dig obegränsat antal exekveringar men kräver grundläggande serveradministration.
Du kan behålla verifieringslogiken som den är och ändra vad som händer efter att “verified_signature” satts till true. Vanliga justeringar är att slå ihop extra metadata i Combine Payloads, routa fel till en säkerhetskanal i Slack eller lägga till en HTTP Request-nod för att logga nekade payloads till din SIEM. Om du använder Gmail nedströms är den enklaste regeln brutal: tillåt bara att Gmail-noden körs när verified_signature är true.
Oftast beror det på att Signing Secret är fel eller kopierad från fel Slack-app. Dubbelkolla hemligheten i din Slack-apps dashboard (General Information) och säkerställ att ditt huvudflöde skickar vidare den råa body:n och Slack-signaturheaders exakt som de togs emot. Timestamp-problem kan också ställa till det om serverklockan går fel, så verifiera maskinens tid om felen verkar slumpmässiga.
Hög. Signaturverifiering går snabbt, så den praktiska gränsen är din n8n-plan eller serverstorlek, inte logiken i sig.
För signaturverifiering är n8n oftast ett renare val eftersom du kan köra kryptokontrollen, förgrening och “hård stopp”-beteende i ett återanvändbart subarbetsflöde. Du får också självhosting, vilket spelar roll när du vill ha full kontroll över hanteringen av inkommande webhooks. Zapier och Make kan fungera bra för enkel routing, men de är inte byggda kring säkerhetsgrindar som den här, och att återskapa exakt Slacks signature base string kan vara pilligt. Om du är osäker, prata med en automationsexpert så mappar vi det säkraste alternativet för din setup.
När du slutar lita på inkommande webhooks som standard försvinner mycket av den nedströms risken. Sätt upp grinden, återanvänd den överallt och låt Slack- och Gmail-åtgärder köras bara när förfrågan bevisligen är äkta.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.