対象：Express（Node.js）でAPIやアプリを運営している人。ここでは攻撃手順は扱わず、最小フレームワークに『自分で足す』守りを解説します。全体像は フレームワーク別セキュリティの入口 も参照。
「自分で足す」守り（既定にない領域）
Expressはルーティングとミドルウェアの土台だけを提供します。次の防御はあなたが足さないと存在しません。
セキュリティヘッダ
CSP/HSTS/X-Content-Type等。helmet相当で付与。
入力の検証
未検証の入力がSQLi/XSS/インジェクションの入口に。
認可（所有者スコープ）
認証だけで止めるとID差し替えで他人のデータ（IDOR）。
レート制限
ログイン総当り・API濫用・DoSを抑える。
依存(npm)のCVE
大量の依存の既知脆弱性を機械監視＋即パッチ。
秘密とSSRF
秘密はenv・コード非混入／外部URL取得はSSRF対策。
塞ぎ方（最低限の5つ）
セキュリティヘッダを付ける
すべての入力を検証・サニタイズ
認証だけで止めず認可を書く
やりがち（危険）
- ヘッダを付けず素のレスポンス
- 入力を検証せずDBやHTMLへ
- 認可を書かず「ログイン＝許可」
- レート制限なし・依存CVE放置
正しい
- helmet相当でヘッダ付与
- 入力を検証・サニタイズ
- 所有者スコープの認可
- レート制限＋依存CVE監視＋即パッチ
当サイトの視点：最小フレームワークは『自由と責任』がセット
Expressの良さは軽さと自由度ですが、それは守りも自分で設計するという意味です。当サイトは別スタックですが、Node系で守る要点は同じ——ヘッダを付け、入力を検証し、公開入口には必ず認可を書き、依存は毎デプロイ前にCVE監査する。とくにNodeは依存の数が多く、依存の鮮度が事故を分けます。「フレームワークが守ってくれるはず」という前提を捨て、防御を明示的に足すことが、Expressの正しい使い方です。
次に読む
- 入口：フレームワーク別セキュリティ（入口） ／ Next.jsのセキュリティ対策（同じNode系）
- 実務：依存のCVE監視 ／ ツール：セキュリティヘッダ診断
- 用語：IDORとは ／ SSRFとは
よくある質問
QExpressは安全なフレームワークですか？
Expressは『最小主義』の設計で、ルーティングとミドルウェアの土台だけを提供し、セキュリティ機能はほとんど内蔵していません。つまり安全でも危険でもなく、守りは開発者が自分で足す前提です。RailsやLaravelのように多くを既定で守ってくれるフレームワークと違い、ヘッダ・入力検証・認可・レート制限などを自分で組み込む必要があります。自由度が高いぶん、責任も自分にあります。
Qhelmet のようなセキュリティヘッダは必要ですか？
はい。Expressは既定でセキュリティ関連のHTTPヘッダを付けません。helmet相当のミドルウェアでCSP・HSTS・X-Content-Type-Options などを付与し、クリックジャッキングやMIMEスニッフィング等の初歩的なリスクを下げるのが基本です。付けるだけで底上げになるので、最初に入れておく価値があります。
Q最低限、何をすればいいですか？
(1) セキュリティヘッダ（helmet相当）を付ける、(2) すべての入力を検証・サニタイズする、(3) ログイン（認証）だけで止めず所有者スコープの認可を書く、(4) ログインやAPIにレート制限をかける、(5) 依存パッケージ(npm)のCVEを機械監視して即パッチ。この5つで、最小フレームワークの穴の大半を埋められます。