Security and Secrets Management

Automation workflows frequently handle sensitive data — API keys, customer emails, payment information, authentication tokens. A single misconfigured workflow can expose all of it. Security isn't optional. The most common security mistakes in automation: hardcoding API keys in workflow nodes (visible to anyone with workflow access, stored in plaintext in n8n's database), using overly permissive API scopes (requesting 'full access' when you only need 'read'), exposing webhook URLs without authentication (anyone can trigger your workflows), logging sensitive data (customer emails, API responses containing PII stored in execution logs), and running n8n without HTTPS. Secrets management: use n8n's built-in Credentials system for all API keys. Credentials are encrypted in n8n's database. Even better, integrate n8n with an external secrets manager — n8n supports fetching secrets from HashiCorp Vault, AWS Secrets Manager, and similar tools. This way, credentials are never stored in n8n's database at all. Least privilege principle: every API integration should use the most restricted permission scope that still allows the workflow to function. If your workflow only reads from a Google Sheet, use a service account with read-only access — not your personal Google account with full Drive access. If you're compromised, the blast radius is minimal. Webhook security: every webhook should verify the sender's signature before processing. We covered this on Day 12 — implement it for all production webhooks. Additionally, use IP allowlisting where possible — if Stripe only sends webhooks from known IP ranges, block all other IPs at the webhook endpoint.

Automation workflows process personal data — names, emails, behavior data. Depending on your jurisdiction, GDPR, CCPA, or the Australian Privacy Act imposes obligations on how this data is handled, even in internal workflows. Key data privacy requirements for automation: data minimization (only collect and process the fields you actually need), retention limits (delete processed data after a defined period — don't keep execution logs with PII indefinitely), subject access requests (if a user asks what data you hold about them, your automation data stores need to be searchable by identifier), and cross-border transfers (if you're in Australia and using US-based automation tools, understand what data leaves the country). In n8n, configure execution data retention: Settings > Execution Data > set 'Prune Data' to delete executions after 7-30 days. For executions containing PII, reduce this to the minimum needed for debugging. Pseudonymization: where possible, replace real identifiers with pseudonyms before passing data to third-party APIs. Instead of sending 'john.smith@acme.com' to an AI API for classification, send 'user_39472@internal'. Store the mapping in your own database. This limits the data shared with external services. Audit logging: for compliance, maintain an audit log of what actions your workflows took and when. This is different from n8n's execution log — it's a business-level record: 'At 14:32 on 2024-01-15, workflow CRM-Sync updated contact record #4821 with new email address'. Store this in your own database.