GitHub to Slack, block fake webhook alerts
Your Slack shouldn’t be a public suggestion box. Yet one spoofed webhook call can drop a “new issue” alert into a busy channel, waste time, and send someone chasing a problem that never happened.
This GitHub Slack security automation hits DevOps teams first, but engineering managers and agency operators running client repos feel the same pain. You will stop fake GitHub events at the door, so only real repo activity can trigger alerts and downstream actions.
Below, you’ll see how the workflow verifies GitHub’s signature, returns the right HTTP status instantly, and then continues with your normal logic (like Slack notifications) only when the request is legit.
How This Automation Works
The full n8n workflow, from trigger to final output:
n8n Workflow Template: GitHub to Slack, block fake webhook alerts
flowchart LR
subgraph sg0["Flow 1"]
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/webhook.dark.svg' width='40' height='40' /></div><br/>Respond 200 OK"]
n1["<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/webhook.dark.svg' width='40' height='40' /></div><br/>Respond 401 Unauthorized"]
n2["<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/webhook.dark.svg' width='40' height='40' /></div><br/>GitHub Webhook"]
n3@{ icon: "mdi:cog", form: "rounded", label: "Compute HMAC256", pos: "b", h: 48 }
n4@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Validate HMAC256", pos: "b", h: 48 }
n5["<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/github.dark.svg' width='40' height='40' /></div><br/>Get the profile of a reposit.."]
n6@{ icon: "mdi:location-exit", form: "rounded", label: "Stop and Error", pos: "b", h: 48 }
n2 --> n3
n0 --> n5
n3 --> n4
n4 --> n0
n4 --> n1
n1 --> 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 decision
class n0,n1,n2 api
classDef customIcon fill:none,stroke:none
class n0,n1,n2,n5 customIcon
The Problem: Fake Webhook Alerts Pollute Slack
GitHub webhooks are simple: GitHub sends an HTTP request to your n8n webhook URL whenever something happens. That simplicity is also the risk. If you don’t verify the request, anyone who finds (or guesses) your webhook endpoint can post a lookalike payload and trigger the same “real” automations. In practice, that means noisy Slack alerts, wasted triage cycles, and a creeping lack of trust in your notifications. And once trust is gone, teams start ignoring Slack entirely. Bad place to be.
The friction compounds. Here’s where it breaks down.
- One spoofed “push event” can send your team into 20 minutes of pointless checking and backtracking.
- Alert fatigue kicks in fast, so genuine incidents get missed because people stop believing the feed.
- Basic allowlists aren’t enough when you have multiple repos, rotating IPs, or shared infrastructure.
- If your webhook triggers expensive steps (API calls, builds, report generation), fake calls can run up costs and burn execution quota.
The Solution: Verify GitHub’s Signature Before Anything Runs
This workflow acts like a security checkpoint in front of your GitHub-triggered automations. When GitHub calls your n8n webhook, the workflow immediately computes its own HMAC SHA-256 signature using the shared secret you configured inside your GitHub webhook settings. Then it compares that computed signature to the x-hub-signature-256 header GitHub includes with every signed webhook request. If they match, n8n returns a clean 200 response to GitHub and continues into your real business logic (for example, grabbing repo details and sending Slack alerts). If they don’t match, it returns 401 Unauthorized and stops, optionally logging the attempt so you can see that something shady hit your endpoint.
The workflow starts with an incoming GitHub webhook call. From there, it generates an HMAC256 hash, checks equality, and responds immediately with either 200 (good) or 401 (bad). Only validated events move forward to GitHub API calls and whatever you plug in next, like Slack notifications.
What You Get: Automation vs. Results
| What This Workflow Automates | Results You’ll Get |
|---|---|
|
|
Example: What This Looks Like
Say your team monitors 10 GitHub events a day and each alert sends someone to check the repo, open CI, and confirm what changed. If even 2 of those are fake or tampered, that’s about 40 minutes of distraction, plus the context switching (honestly the worst part). With this workflow, you spend maybe 20 minutes once to set the secret in GitHub and n8n, and every bad call gets a fast 401 before Slack ever sees it. The “after” experience is boring in the best way: real event comes in, real alert goes out, done.
What You’ll Need
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- GitHub for webhook source events and repo data.
- Slack to deliver alerts after validation (your own step).
- GitHub webhook secret (create it in the webhook “Secret” field).
Skill level: Intermediate. You’ll copy a secret key, paste it into n8n, and be comfortable testing webhooks with real GitHub events.
Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).
How It Works
A GitHub webhook hits your n8n URL. The workflow is triggered the moment GitHub sends an event to your “Incoming GitHub Hook” endpoint, along with headers that include x-hub-signature-256 if you set a secret in GitHub.
The workflow computes its own signature. n8n takes the raw request body and generates an HMAC256 hash using the same secret you configured in GitHub. This mirrors GitHub’s signing method, so you’re comparing like for like.
The signature is verified before anything else runs. If the computed hash matches the header, the workflow routes down the “approved” path. If it doesn’t match, the workflow returns a 401 and can optionally stop with an error so you can track attempts inside n8n.
Verified requests continue into your real automation. In the sample workflow, the “good” path returns a 200 response and then retrieves repo profile details from GitHub. This is the spot where you’d add Slack, Google Sheets logging, Drive archiving, or whatever your team needs.
You can easily modify the post-validation logic to send different Slack messages based on event type, repo name, or branch. See the full implementation guide below for customization options.
Step-by-Step Implementation Guide
Step 1: Configure the Webhook Trigger
Set up the inbound GitHub webhook endpoint that receives payloads for signature validation.
- Add the Incoming GitHub Hook node as your trigger.
- Set HTTP Method to
POST. - Set Path to
github-test. - Set Response Mode to
responseNodeso replies are handled by response nodes.
Step 2: Set Up the HMAC Hash Generation
Generate the HMAC SHA256 signature from the raw GitHub payload so it can be compared against the header signature.
- Add the Generate HMAC256 Hash node after Incoming GitHub Hook.
- Set Type to
SHA256and Action tohmac. - Set Value to
={{ JSON.stringify($json.body) }}. - Set Secret to your GitHub webhook secret (replace
[CONFIGURE_YOUR_API_KEY]). - Set Data Property Name to
=signature-256.
Step 3: Configure Signature Verification Logic
Compare the computed signature to the x-hub-signature-256 header and route the flow accordingly.
- Add the Verify HMAC Signature node after Generate HMAC256 Hash.
- Set the condition to compare Left Value
={{ $json['signature-256'] }}with Right Value={{ $json.headers['x-hub-signature-256'].split('=').pop() }}. - Confirm the operator is equals with strict validation to prevent false positives.
Verify HMAC Signature routes to Return Success 200 on match and to Return Unauthorized 401 on mismatch.
Step 4: Configure Output and GitHub Actions
Return the appropriate HTTP response and fetch repository details after successful validation.
- Configure Return Success 200 with Respond With set to
noDataand Response Code200. - Connect Return Success 200 to Retrieve Repo Profile for post-validation data retrieval.
- In Retrieve Repo Profile, set Resource to
repositoryand Operation togetProfile. - Set Owner to
={{ $json.body.repository.owner.html_url }}and Repository to={{ $json.body.repository.html_url }}. - Credential Required: Connect your githubApi credentials in Retrieve Repo Profile.
Step 5: Add Error Handling
Return an unauthorized response and halt execution when the signature does not match.
- Configure Return Unauthorized 401 with Respond With set to
noDataand Response Code401. - Connect Return Unauthorized 401 to Halt With Error.
- In Halt With Error, set Error Message to
HMAC256 signature doesn't match provided signature. Make sure that the GitHub webhook secret is identical to the secret stored in the 'Compute HMAC256' node.
Step 6: Test and Activate Your Workflow
Validate the end-to-end flow, then enable it for production use.
- Click Execute Workflow and send a test webhook from GitHub to the Incoming GitHub Hook URL.
- Confirm that a valid signature routes through Verify HMAC Signature to Return Success 200 and triggers Retrieve Repo Profile.
- Send an invalid signature to verify the flow reaches Return Unauthorized 401 and stops at Halt With Error.
- Once successful, toggle the workflow to Active to enable production execution.
Common Gotchas
- GitHub webhook secrets must match exactly on both sides. If validation suddenly fails, check the GitHub webhook “Secret” field and the n8n HMAC node value first.
- If you add Wait nodes or external processing after the 200 response, remember that GitHub only cares about the immediate response. Keep the validation and response fast, then do heavier work after.
- The secret is stored in plain text inside the workflow. If you share workflows, commit them to source control, or hand them to clients, treat that value like a password and rotate it when needed.
Frequently Asked Questions
About 30 minutes if your GitHub webhook is already created.
No. You’ll paste in a secret, map a couple fields, and run a test event from GitHub.
Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in GitHub plan limits if you hit API rate caps.
Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.
Yes, and that’s the whole point. Keep the “Generate HMAC256 Hash” and “Verify HMAC Signature” logic as-is, then replace the sample “Retrieve Repo Profile” step with your Slack action (or any other business logic). Common tweaks include routing alerts to different channels by repo, ignoring low-value events, or logging every verified event to Google Sheets for audit trails.
Most of the time it’s not GitHub “auth” at all, it’s signature validation failing because the webhook secret doesn’t match. Confirm the secret in the GitHub webhook settings, then confirm the exact same value is used in the HMAC node in n8n. Also check that your webhook endpoint in n8n is receiving the raw body as expected, because even small transformations can change the computed signature.
A lot.
For signature verification, n8n is usually the better fit because you can control the request handling, compute hashes, and branch logic without fighting platform limits. Zapier and Make can work, but HMAC verification is harder to implement cleanly and you may end up paying for extra steps just to do basic security checks. If you only need “send a Slack message when GitHub fires,” those tools are fine. The moment you care about spoofing, tampering, or conditional routing, n8n feels less restrictive. Talk to an automation expert if you want help choosing.
Once this is in place, Slack becomes reliable again. The workflow rejects the junk, and your team gets back to shipping.
Need Help Setting This Up?
Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.
