CSRF risk on webhook in n8n
Why GET webhooks performing actions are vulnerable to cross-site request forgery
What is this issue?
Cross-Site Request Forgery (CSRF) attacks can trick users into unknowingly triggering your webhook. GET webhooks that perform write operations (database updates, sending emails, external API calls) are especially vulnerable since GET requests can be triggered by simple links or images.
Vulnerable patterns:
•GET webhook that updates database records•GET webhook that sends emails or notifications•GET webhook that deletes or modifies data•GET webhook without any authentication
Why is this dangerous?
Unauthorized actions
Attackers can place links on any website that trigger your workflow when users click them.
Data manipulation
Attackers can modify data by tricking authenticated users into visiting malicious pages.
User impersonation
Actions are performed in the context of the victim user's session/identity.
Difficult attribution
Attacks look like legitimate user actions, making forensics difficult.
How to fix it
- 1
Use POST for state changes
Change webhooks that perform write operations to use POST method instead of GET.
- 2
Add authentication
Require Basic Auth, Header Auth, or token validation on all webhooks.
- 3
Validate origin
Check the Origin or Referer header to ensure requests come from expected sources.
- 4
Use CSRF tokens
For forms, include a unique token that must be present in the request body.
Scan your workflow now
Upload your n8n workflow JSON and detect GET webhooks that perform write operations.