CSRF risk on webhook in n8n
- Feb 12
- 1 min read
What this means (non-technical)
This happens when a webhook uses the GET method to perform actions like updating data, sending emails, or triggering changes. GET requests can be triggered by simply visiting a link or loading an image in a browser.
If no authentication is required, anyone can cause that webhook to run.
What usually goes wrong
A malicious website can embed a link that silently triggers your webhook when someone visits it.
If the victim is logged into a related system, the action may run in their context.
The result can be:
Unintended database updates.
Messages being sent without approval.
Records being modified without clear explanation.
Because the request looks legitimate, it’s difficult to understand how it happened.
When this becomes urgent
This becomes urgent when:
The webhook performs write operations.
It deletes or modifies records.
It triggers billing, notifications, or external calls.
It is publicly accessible.
The more powerful the action, the more careful you need to be about how it is triggered.
Detect issues in your n8n workflows
|
Definitions
GET request: A type of web request typically meant for retrieving data, not changing it.
CSRF (Cross-Site Request Forgery): An attack where a user is tricked into triggering an action without realizing it.
Disclaimer
This article highlights common patterns and risks seen in real-world n8n workflows. It’s meant to help you build more confidently and avoid surprises as your automation grows. Behavior can vary depending on your setup, version, and configuration.