Feb 18, 2026

n8nを安全に運用する7つのセキュリティ設定

n8nをセルフホストで動かしている人、増えてきた。ノーコードで自動化ワークフローを組めるのは便利だけど、セキュリティ設定をデフォルトのまま放置していないだろうか。

結論から言うと、n8nには環境変数で有効化できるセキュリティ機能がいくつもある。今回はその中から「これは設定しておいたほうがいい」という7項目を紹介する。

1. HTTPS通信を必須にする

まず基本中の基本。n8nへのアクセスはHTTPSで保護する。

方法は2つある。リバースプロキシ（NginxやCaddyなど）でTLSを終端するか、n8nに直接証明書を渡すか。公式ドキュメントではリバースプロキシ方式が推奨されている。

直接渡す場合はN8N_SSL_CERTとN8N_SSL_KEYで証明書ファイルのパスを指定する。ただし証明書の更新運用が発生するので、Let’s Encrypt＋リバースプロキシのほうが楽だと思う。

2. CookieをHTTPS専用に強化する

HTTPSを有効にしたら、Cookieの設定も合わせて強化する。

N8N_SECURE_COOKIE=true

これでHTTPS以外の接続にはCookieが送られなくなる。デフォルトでtrueになっているはずだが、明示的に設定しておくと安心。

N8N_SAMESITE_COOKIEも確認しておくといい。デフォルトはlaxで、多くの場合はこれで問題ない。strictにするとより厳格になるが、外部サービスとの連携で問題が出ることもある。noneはHTTPS必須かつクロスサイト送信を許可するので、特別な理由がなければ避けたほうがいい。

3. リバースプロキシ配下ではWebhook URLを明示する

n8nをリバースプロキシの後ろに置いていると、Webhook URLが意図しない形で生成されることがある。内部では5678番ポートで動いていても、外部には443で公開している場合、URLがズレる。

これを防ぐにはWEBHOOK_URLで外部公開URLを明示的に指定する。

WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

N8N_PROXY_HOPSはプロキシの段数を指定する。1段なら1。これとセットで、プロキシ側でX-Forwarded-For、X-Forwarded-Host、X-Forwarded-Protoヘッダを正しく付与する設定も必要になる。

ここを間違えると、外部サービスからのWebhook呼び出しが失敗したり、HTTPでリダイレクトされたりする。地味にハマりやすいポイント。

4. 環境変数へのアクセスを遮断する

n8nのExpressionやCodeノードからは、デフォルトで環境変数を参照できてしまう。つまり、ワークフローを作れる人がprocess.env経由でDBパスワードやAPIキーを覗ける可能性がある。

N8N_BLOCK_ENV_ACCESS_IN_NODE=true

これを設定すると、式やCodeノードから環境変数を参照できなくなる。複数人でn8nを使っている環境では特に重要。自分一人で使っていても、万が一ワークフローをエクスポートして共有したときに秘密情報が漏れるリスクを減らせる。

5. ファイルアクセスを制限する

n8nはファイルの読み書きができるノードを持っている。便利な反面、設定ファイルや.n8nディレクトリにアクセスされると困る。

N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true
N8N_RESTRICT_FILE_ACCESS_TO=/data/uploads;/data/exports

前者はn8nの設定ファイルや.n8n配下へのアクセスをブロックする（デフォルトでtrue）。後者は読み書きできるディレクトリを明示的に限定する。複数指定する場合はセミコロン区切り。

「このディレクトリだけ」と絞っておくことで、意図しないファイル操作を防げる。

6. 使わないAPIとノードを無効化する

n8nにはPublic REST APIがあるが、外部から使う予定がなければ閉じておく。

N8N_PUBLIC_API_DISABLED=true
N8N_PUBLIC_API_SWAGGERUI_DISABLED=true

Swagger UIも一緒に無効化しておくと、APIの仕様が外部に見えることもなくなる。

さらに、危険な操作ができるノード自体を使えなくするオプションもある。

NODES_EXCLUDE=n8n-nodes-base.executeCommand,n8n-nodes-base.readWriteFile

executeCommandはシェルコマンドを実行できるノード。複数人でn8nを使っている環境や、ワークフロー作成を他の人に任せている場合は、こうしたノードをUIから消しておくのが無難。

7. セキュリティ監査を定期的に実行する

設定したつもりでも抜けがあるかもしれない。n8nには監査機能が組み込まれている。

n8n audit

CLIで実行すると、Credentials、Database、File system、Nodes、Instanceの5系統でチェックが走る。未保護のWebhook、不足しているセキュリティ設定、バージョンが古いかどうかなどを検出してくれる。

REST API経由でPOST /auditを叩くこともできる（インスタンスオーナー権限が必要）。

ただし、この監査で検出できる範囲には限界がある。ファイアウォールの設定やWAFの有無、OSレベルのパッチ適用などは別途確認が必要。監査結果がクリーンだからといって安心しすぎないこと。

どこまでやるかは環境次第

7項目を紹介したが、全部を一律に適用する必要はない。

自分一人で使っているローカル環境なら、HTTPS化と環境変数のブロックくらいで十分かもしれない
社内で複数人が使う場合は、危険ノードの無効化やファイルアクセス制限まで踏み込んだほうがいい
外部に公開している（Webhookを外から叩かれる）なら、すべての項目を見直す価値がある

「便利だから」と雑に公開していると、思わぬところから情報が漏れる。ノーコードツールは敷居が低い分、セキュリティ設定も軽視されがち。使う前に一度、環境変数の一覧を眺めておくだけでもリスクは下がる。