対象：Express（Node.js）でAPIやアプリを運営している人。ここでは攻撃手順は扱わず、最小構成のフレームワークに自分で追加する対策を、本番向けの実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）として示します。全体像は フレームワーク別セキュリティの一覧 も参照。
優先度つきハードニング・チェックリスト
まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用で守る項目です。
P0 ── 前提（まずこれ）
ヘッダ(helmet)＋x-powered-by無効 ／ 依存(npm)CVE監視 ／ 秘密を環境・スタック非露出
P1 ── 最頻の事故源
入力検証とインジェクション対策 ／ 所有者スコープの認可
P2 ── 継続的な運用
レート制限・サイズ上限 ／ セッション・Cookie・CSRF ／ SSRF
| 優先 | 対策 | 具体（Express） |
|---|---|---|
| P0 | セキュリティヘッダ | helmet相当で CSP/HSTS/X-Content-Type 等。x-powered-by を無効化 |
| P0 | 依存(npm)CVE | npm audit/osv-scanner で監視・実稼働版で判定し即パッチ |
| P0 | 秘密とエラー | 秘密は環境変数から。本番でスタックトレースを外部に出さない |
| P1 | 入力検証 | 受け取り値を検証・サニタイズ（型・範囲・許可値）。ボディサイズ上限 |
| P1 | インジェクション | DBはバインド。NoSQLの演算子注入($)に注意。eval に入力を渡さない |
| P1 | 認可 | 認証＋各ルートで所有者スコープの認可。JWTは署名検証・alg固定 |
| P2 | レート制限 | ログイン/APIに試行/流量の制限。総当り・濫用・DoSを抑える |
| P2 | セッション/Cookie | secure/httpOnly/sameSite。CSRF（Cookieセッション時）。本番用セッションストア |
| P2 | SSRF | サーバー側の外部取得は許可先限定＋内部IP/メタデータ遮断 |
1. セキュリティヘッダと露出削減（P0）
Expressは既定でセキュリティヘッダを付けません。まずここから追加します。
- helmet相当のミドルウェアで CSP・HSTS・X-Content-Type-Options・frameguard 等を付与する。
x-powered-byを無効化し、フレームワーク/バージョンの露出を減らす。- 自サイトの状態は セキュリティヘッダ診断 で確認できる。
2. 依存（npm）とサプライチェーン（P0）
- 依存の既知CVEを
npm auditや osv-scanner で機械監視し、実稼働版で判定して即パッチ（→ 依存のCVE監視）。 - Nodeは依存数が多く、サプライチェーン攻撃のリスク（typosquatting・
postinstallフック等）もある。導入時に吟味し、数を絞る。 - Node をサポート対象(LTS) に保ち、EOL版を放置しない。
3. 入力検証とインジェクション（P1）
- すべての入力（ボディ・クエリ・パラメータ・ヘッダ）を検証・サニタイズする。ボディサイズの上限を設けDoSを抑える。
- SQLはプレースホルダでバインドし、文字列連結でクエリを組まない（→ SQLインジェクションとは）。
- NoSQLでは、オブジェクト型の入力による演算子注入(
$)に注意する（クエリに生オブジェクトを渡さない）。 eval等の危険な評価に外部入力を渡さない。
4. 認証と認可（P1）
やりがち（危険）
- 認可を書かず「ログイン＝実行可」
- ミドルウェアの順序/存在だけに依存
- IDやフラグをクライアントから来たまま信用
- JWTの署名未検証・
alg:none許容
正しい
- 認証に加えて各ルートで所有者スコープの認可
- 認可はデータに近い場所で確認（順序頼みにしない）
- サーバー側で再検証（IDの差し替えに耐える）
- JWTは署名検証必須＋alg固定（
alg:none拒否）
用語は IDORとは ／ JWTとは。JWTの内容は自分で検査できる（JWTデコーダ）。
5. レート制限と濫用対策（P2）
- ログイン・API・パスワードリセットに試行/流量の制限をかけ、総当りや濫用・DoSを抑える。
- リクエストボディやアップロードのサイズ上限を設ける（大きなペイロードによるメモリなどの使い切りを防ぐ）。
6. セッションと Cookie（P2）
- セッションCookieに
secure/httpOnly/sameSiteを設定する。 - Cookieセッションのアプリは CSRF対策を入れる（→ CSRFとは）。
- 本番では適切なセッションストアを使う（既定のインメモリは本番不可）。ログイン時にセッションを再生成する。
7. SSRF とサーバー側の外部取得（P2）
- サーバーがユーザー指定URLを取得する処理は許可先を限定し、接続時に内部IP／クラウドのメタデータへの到達を遮断する（→ SSRFとは）。
8. エラー処理と本番設定（P0〜P2）
- 集中エラーハンドラで例外を処理し、スタックトレースやスタック情報を外部に出さない。
NODE_ENV=productionで動かす。プロキシ配下ではtrust proxyを正しく設定し、スキームやクライアントIPを誤認しないようにする。- TLS/HTTPS を終端で確実に。
検証：自分のExpressは固められているか
作ったら終わりではありません。点検して初めて完了です。以下は自分の環境に対する防御的な自己チェックです。
ヘッダと露出
x-powered-by が消えていることを ヘッダ診断で確認。エラーで内部が出ないか
認可が効くか
依存とレート制限・SSRF
npm audit/osv がクリーンか、ログインにレート制限が効くか、外部取得が内部IPへ到達しないかを確認。当サイトの視点：最小構成のフレームワークは、対策も自分で設計する
Expressの良さは軽さと自由度ですが、それは守りも自分で設計するという意味です。RailsやLaravelが既定で用意している部分（ヘッダ・CSRF・認可の仕組み）を、Expressでは意識して組み込みます。重点は、上の表を上から順に実施し、ヘッダを付け・入力を検証し・公開しているエンドポイントに認可を書き・依存をCVE監視すること。とくにNodeは依存の数が多く、依存を最新に保てるかどうかが事故を左右します。「フレームワークが守ってくれるはず」という前提を捨て、防御を明示的に足すのが正しい使い方です。
次に読む
- 一覧：フレームワーク別セキュリティ（一覧） ／ Next.jsのセキュリティ対策（同じNode系）
- 実務：依存のCVE監視 ／ 脆弱性(CVE)対応の実務
- 用語：IDORとは ／ SSRFとは ／ JWTとは ／ CSRFとは
- ツール：セキュリティヘッダ診断 ／ JWTデコーダ
出典と確認範囲
以下は上記の設定・影響範囲・対策を確認するための原典です。2026年10月23日に参照先を確認しました。各版・構成の条件は原典で確認してください。チェックリストの優先順位や教訓は当サイトの整理であり、記事全体の再検証や安全性の保証を意味しません。