SQL injection risk in n8n
- Feb 12
- 2 min read
What this means (non-technical)
This happens when you build a SQL query by directly inserting user input into the query string. For example, you take a value from a webhook and place it straight into a query like:
SELECT * FROM users WHERE id = '${id}'
Instead of treating the input as data, the database treats it as part of the command itself.
What usually goes wrong
If someone sends unexpected input, it can change the meaning of your query.
Instead of just filtering one record, the query could return far more data than intended. In some cases, it could even modify or delete records.
The workflow may appear to work normally most of the time. Then one unusual input causes:
Sensitive data to be exposed.
Records to be changed incorrectly.
Login or permission checks to be bypassed.
These failures are often surprising and hard to trace back to a single string inside a query.
When this becomes urgent
This becomes urgent when:
Your workflow receives input from webhooks or forms.
It connects to a production database.
It handles customer or financial data.
Multiple people can send data into the workflow.
The more public the input and the more valuable the data, the more serious the risk.
Detect issues in your n8n workflows
|
Definitions
SQL: A language used to query and modify databases.
User input: Any data coming from outside the workflow, such as a form, webhook, or API request.
Parameterized query: A safer way to send data to a database where values are treated strictly as data, not executable instructions.
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.