The Log That Told Everyone the Password: Redacting Secrets in n8n Execution Logs

Description and use

Secrets in n8n can leak through execution logs when hard‑coded, logged, echoed in errors, or exported. Mitigations involve credential‑only storage, log scrubbing, export grepping, retention reduction, and key rotation.

Problem

Secrets can be inadvertently exposed in n8n execution logs when they are hard‑coded in node inputs, logged during debugging, echoed in error responses, or exported with workflow JSON.

Outcome

Implementing strict credential usage, log scrubbing, export grepping, retention control, and key rotation significantly reduces secret exposure in n8n workflows.

Workflow

• 1. Store every secret in a credential and never paste it into node inputs.
• 2. Avoid logging entire objects; log only necessary fields.
• 3. Scrub error outputs before forwarding to external systems.
• 4. Reduce execution retention for sensitive workflows.
• 5. Grep workflow JSON exports for secret patterns before sharing.
• 6. Rotate any key that has leaked.
• 7. Test workflows with a dummy secret and search all artifacts for it before shipping.

Evidence

n8n credentials are encrypted at rest, and that lulls you into thinking secrets are handled.

Source

A secret may exist in exactly one place — the credential store — and every other place it appears is a leak, even if that place is "only" my own dashboard.

Source

If a workflow touches payments, inboxes, or customer data, it does not need its full execution history kept indefinitely.

Source

I keep a dummy secret — a fake key that looks real — and run it through the workflow end to end: trigger it, force an error, export the workflow, and then search every artifact for the dummy value.

Source