If you ship an n8n workflow, you already know the drill: the nodes work in the editor, then the moment it runs in production something quietly breaks. I have reviewed a lot of these now. The failures are not exotic. They are the same four, over and over.
Here are the four, with the exact node-level checks that catch each one. No theory. Run these before you take a payment.
1. A webhook that accepts anything
The default n8n Webhook node listens on a path and trusts whatever POSTs to it. If you do not set authentication, anyone who guesses the path can fire your workflow. In the editor it is invisible, because the editor never simulates an attacker.
The check: open the Webhook node and look at Authentication. It should be set to something that requires a credential — Basic Auth with a strong password, or a header the caller must send. If it says "None", that path is open.
2. Credentials sitting in the node config
n8n stores credentials by reference, which is safe. The trap is when someone pastes a key straight into a node's "value" field, or when a credential gets exported with the workflow JSON. Then the secret is in version control forever.
The check: grep your workflow exports for anything that looks like a key or token. If you find one, delete it from the file and rotate the credential, because it has already been exposed.
3. A workflow that runs twice on one trigger
n8n retries on error. Webhooks can fire twice. If your workflow is not idempotent, one trigger can send two emails, create two records, or charge a customer twice. The fix is a dedup key: store the execution id or webhook payload id in a table with a unique constraint, and skip if it is already there.
4. Secrets in the error message
When a node fails, n8n can include the full error object, including credential values, in the execution log. Anyone with access to the log — or worse, a log that gets shipped to a monitoring service — gets the secret.
The check: in the Error Workflow or the node's "On Error" settings, make sure "Include Error Details" does not expose credentials. And never email or webhook the full error body to a third party.
Why these keep shipping
Every one of these compiles, renders, and passes the test run. The failure only shows up under a retry, an attacker, or a log review, long after launch. The generator optimizes for the happy path you can see and skips the boundary you cannot.
If you want the production-ready versions of these checks — with n8n node templates, a dedup table schema, and a credential-audit script — they are in the production hardening pack. It is set up for Cursor and Bolt, so you can drop the checks into any existing workflow in one pass.
Get it here: https://ancuboy.gumroad.com/l/cursor-bolt-production-hardening-pack
Use code VIBE30 for 30% off. It is the same pack this article is based on.
Top comments (0)