Security & Redaction

Relevant source files

The following files were used as context for generating this wiki page:

• AGENTS.md
• cubic.yaml
• CONTRIBUTING.md
• packages/nodes-base/AGENTS.md
• packages/@n8n/ai-workflow-builder.ee/src/code-builder/prompts/index.ts

The n8n security system protects sensitive information through multi-layered defense mechanisms, including an encryption boundary, automated PII (Personally Identifiable Information) redaction, and strict hygiene for security fixes. These systems ensure that credentials, customer data, and vulnerability details remain confidential within the codebase and public artifacts.

Encryption Boundary

The project enforces an encryption boundary to manage sensitive data. New code must use the central cipher module for all encryption and decryption operations.

Cipher Implementation

Developers must use cipher.encryptV2() and cipher.decryptV2() for handling sensitive data. The key-manager module selects the appropriate key and output format. To prevent data loss, the system never deletes deployment keys; it only deactivates them. Database triggers reject direct deletion attempts of these keys.
Sources: AGENTS.md:195-201

CI Enforcement

Static analysis in CI checks that every package depending on n8n-core or @n8n/db extends the backendConfig or nodesConfig ESLint layers. These layers reject directives like eslint-disable that would bypass encryption rules.
Sources: AGENTS.md:202-209

The diagram shows the flow of data through the encryption boundary, where business logic is restricted from accessing raw AES classes directly.
Sources: AGENTS.md:195-209

PII Redaction and Shared Utilities

n8n provides shared utilities for redacting PII and managing secrets to prevent accidental exposure in logs, telemetry, or AI outputs.

Redaction Utilities

The project requires the use of shared helpers from @n8n/utils for PII and secret redaction. These utilities identify and strip sensitive values from data streams.
Sources: AGENTS.md:65-70

Redaction Logic in AI Workflows

The AI Workflow Builder explicitly manages the inclusion or exclusion of values in execution schemas. A valuesExcluded flag indicates if sensitive data has been redacted from the node execution results before they are passed to the LLM.
Sources: packages/@n8n/ai-workflow-builder.ee/src/code-builder/prompts/index.ts:747-758

Utility Package	Primary Security Responsibility
@n8n/utils	General helpers and PII/secret redaction
@n8n/ai-utilities	AI-specific helpers and response-size limiting
@n8n/typeorm	Restricted to persistence layer only
Sources: AGENTS.md:65-71, AGENTS.md:175-177

Security Fix Hygiene

Because n8n is a public repository, strict hygiene rules prevent the exposure of attack vectors or vulnerability types in public-facing artifacts.

1. Branch Names: Use neutral descriptions (e.g., node-1234-improve-request-handling) instead of naming the vulnerability (e.g., fix-ddos-vulnerability).
2. Commit Messages: Describe the new behavior (e.g., fix: add payload size validation) rather than the threat prevented.
3. Test Descriptions: Use functional language like should sanitize query parameters instead of mentioning SQL injection.
4. No Exploit Details: Code comments and PR descriptions must never describe attack scenarios or exploit paths.
   Sources: AGENTS.md:301-316, cubic.yaml:69-72

Customer Confidentiality

The system forbids naming specific customers in code, tests, or PRs. This protects customer privacy and prevents revealing security-relevant details about specific deployments.

• Use generic placeholders like Acme Corp in tests.
• Describe large-scale setups neutrally (e.g., "a customer with a large multi-main setup") instead of using company names.
• This rule applies to all fixtures, branch names, and commit messages.
  Sources: AGENTS.md:318-325, cubic.yaml:73-74

Node and Credential Security

Community and official nodes follow specific patterns to handle untrusted user input and sensitive credentials.

Untrusted Input Handling

User input arriving through this.getNodeParameter() is considered untrusted. Developers must never use these values as computed object keys in assignments to prevent prototype pollution. The setSafeObjectProperty and isSafeObjectProperty helpers from n8n-workflow must be used for dynamic-key writes.
Sources: packages/nodes-base/AGENTS.md:73-88

Credential Protection

Credentials store sensitive information for connecting to external APIs. The @n8n/eslint-plugin-community-nodes package enforces security rules for these entities:

• Sensitive Field Detection: Fields with sensitive names must have typeOptions.password = true.
• Credential Reuse: Prevents nodes from referencing credentials outside their own package to avoid security issues.
• Dangerous Functions: Disallows eval, the Function constructor, and child_process spawning in community nodes.
  Sources: packages/nodes-base/AGENTS.md:7-14, packages/@n8n/eslint-plugin-community-nodes/README.md:52-84

This sequence illustrates the validation required before writing user-provided data to an object to prevent prototype pollution.
Sources: packages/nodes-base/AGENTS.md:80-92

Command Line and Telemetry Safety

The environment prevents the leakage of secrets through shell history and telemetry recording.

• Dev Metrics: If a developer opts into dev metrics, command arguments for secret-carrying words (e.g., config, token, login) are automatically dropped.
• Environment Variables: Developers must pass sensitive values via environment variables, which the telemetry system never captures.
  Sources: AGENTS.md:18-23

Conclusion

Security and redaction in n8n are achieved through a combination of strict coding standards, automated CI enforcement, and careful management of public metadata. By centralizing encryption in the cipher module and enforcing safe data handling in nodes, the project maintains a high security bar without significantly increasing developer friction.