調べたいことを検索

JWTは、サーバが署名して発行する、改ざんを検出できるトークン。header.payload.signatureの3部からなり、サーバは署名で本物か検証する。要注意＝①署名を必ず検証し期待するalgを固定（alg:none拒否）②中身は誰でも読めるので秘密を入れない③有効期限を短くし失効戦略を持つ。デコード（中身を読む）と検証（署名で本物か確かめる）は別物。

CORSは『別オリジンのJSが自分のAPI応答を読めるか』をブラウザが制御する仕組み。設定ミス＝任意Originの反射や Access-Control-Allow-Origin:* と認証情報の併用で、第三者サイトからログイン済みデータを読まれる。基本の防御は許可リスト方式・Originを鵜呑みに反射しない・既定で拒否。

セッション固定は、攻撃者が用意した既知のセッションIDを被害者に使わせ、ログイン後にそのIDでなりすます攻撃。基本の防御は『ログイン（と権限変化）のたびにセッションIDを再生成する』こと。URLからのID受け取りを禁じ、Cookieには HttpOnly/Secure/SameSite を付ける。

XSSは、攻撃者の用意した文字列が“スクリプトとして”別の利用者のブラウザで実行される脆弱性。セッション窃取・なりすましに直結。基本の防御は『出力時のエスケープ』。フレームワークの自動エスケープを外さないことが最大の対策。

2026年4月19日、Vercelは社内システムへの不正アクセスを公表した。Vercelによれば、社員が使っていた外部のAIツールの侵害を起点に、その社員のGoogle Workspaceアカウント、Vercelアカウント、Vercelの環境へと進まれ、一部の顧客の「sensitive」に設定されていない環境変数が列挙・復号された。影響を受けた顧客には直接連絡済みで、npmで公開しているパッケージは改ざんされていないと確認している。当サイトの結論：漏れたかどうかを分けたのは、環境変数を、保存後も値を画面に表示できる区分にしていたか、表示できない区分にしていたかだった。後から値を見返す必要のない秘密は、すべて値を表示できない区分（Secret）で保存する。社員がOAuth（外部アプリに会社のアカウントへのアクセスを許可する仕組み）でつなぐAIツールも、依存パッケージと同じく棚卸しの対象にする。

Expressは最小構成で、既定ではほとんどセキュリティ対策をしない。対策は開発者が自分で追加する。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝セキュリティヘッダ(helmet)＋x-powered-by無効化・依存(npm)CVE・入力検証とインジェクション(SQL/NoSQL演算子)・認証と所有者スコープの認可・レート制限とサイズ上限・セッション/Cookie/CSRF・SSRF・本番のエラー処理(スタック非露出)・NODE_ENV (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。

認証＝『誰か』を確かめること、認可＝『その人が何をしてよいか』を決めること。両者は別物で、ログインを付けただけでは認可にならない。データに所有者（user_id）でのスコープが無いと『ログイン＝全データ閲覧』になる（OWASP最上位の Broken Access Control）。さらに認証スキャフォールドの登録開放が重なると、第三者が登録して中に入れる。守りは、全クエリを所有者で絞る／不要な登録を閉じる／多層防御／監査・アクセスログを事故の前から残す／新規登録を検知。