Web セキュリティ

XSS は、攻撃者が用意したスクリプトを、他のユーザーが見るページの中で動かす攻撃です。そのサイトのオリジンで動くので、Cookie（HttpOnly でないもの）や画面の情報を盗んだり、ユーザーになりすまして操作したりできます。

フレームワークのエスケープと、危ない書き方

基本の対策は、出力するときに < > & " などを文字として表示されるように変えるエスケープです。React・Vue・テンプレートエンジンは {value} のような埋め込みを自動でエスケープします。ただし次は自動では守られません。

• dangerouslySetInnerHTML・v-html・innerHTML：HTML をそのまま入れる。どうしても必要なら DOMPurify などでサニタイズ（危ないタグや属性を取り除く）してから。
• href・src に入れる URL：javascript:alert(1) が動く。https: などの許可したスキームだけ通す。
• eval・new Function・setTimeout("文字列")。
• サーバー側で JSON を <script> に埋め込むとき（</script> で抜けられる）。

CSP は「このページで動かしてよいスクリプトはどこから来たものか」をヘッダーで決める仕組みで、エスケープ漏れがあったときの二重の守りになります。

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-ランダム値'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

リクエストごとに作る nonce を付けた <script nonce="…"> だけを動かし、インラインのスクリプトや onclick= 属性は止めます。いきなり適用すると画面が壊れることがあるので、まず Content-Security-Policy-Report-Only で違反を集めてから本番にします。'unsafe-inline' を付けると XSS への効果はほぼなくなります。

あわせて、セッションの Cookie は HttpOnly にして、スクリプトから読めないようにします。

CSRF（クロスサイトリクエストフォージェリ）は、ログインしているユーザーに、罠のサイトから本人の意図しないリクエストを送らせる攻撃です。ブラウザは Cookie を自動で付けて送るので、サーバーから見ると本人の操作と区別がつきません。

攻撃の流れ

• ユーザーが bank.example にログインしたまま、攻撃者のページを開く。
• そのページに、bank.example/transfer へ自動で送信されるフォームが仕込まれている。
• ブラウザがログインの Cookie 付きで POST を送り、送金や設定変更が実行される。

攻撃者はレスポンスを読めませんが、「実行させる」だけで被害が出ます。

対策の組み合わせ

トークンを Authorization ヘッダーで送る API（Cookie を使わない）は、ブラウザが自動で付けないので CSRF の心配はほぼありません。ただしそのトークンをどこに保存するかで、今度は XSS への強さが変わります。

SQL インジェクションは、入力値を文字列のまま SQL に連結したせいで、入力の一部が SQL の命令として実行されてしまう攻撃です。データの全件取得・改ざん・削除につながります。

// 危ない：入力が ' OR '1'='1 だと全件が返る
db.query("SELECT * FROM users WHERE email = '" + email + "'");

// 安全：プレースホルダ（値は SQL と別に送る）
db.query("SELECT * FROM users WHERE email = $1", [email]);

プリペアドステートメント

SQL の形（? や $1 の場所）を先に決め、値は後から別に渡す方法です。値はどんな文字が入っていても「値」としてしか扱われないので、命令に化けません。自分でエスケープ関数を書くより確実です。

ORM でも危ない書き方

ORM（オブジェクトと表を対応させるライブラリ）は普通に使えば値をプレースホルダにしますが、文字列を直接渡す機能では守られません。

あわせて、アプリが使う DB ユーザーの権限を必要最小限にし（DROP できないなど）、エラーメッセージに SQL を出さないようにします。

SSRF（サーバーサイドリクエストフォージェリ）は、「URL を受け取って、サーバーがそこへ取りに行く」機能を使って、外からは届かない社内のサーバーやクラウドのメタデータ（169.254.169.254）にアクセスさせる攻撃です。メタデータから一時的な認証情報を盗まれると、クラウドの権限まで奪われます。OWASP Top 10 の 2025年版では「アクセス制御の不備」に含まれています。

「名前解決のときは外の IP、接続のときは内の IP」に変える DNS リバインディングもあるので、確かめた IP にそのまま接続するように作ります。

OWASP Top 10 は、Web アプリでよく起きる危険の種類を、OWASP という団体がまとめた一覧です。数年ごとに改訂され、2026年時点の最新は 2025年版です（2021年版から、SSRF がアクセス制御に統合され、サプライチェーンと例外処理の項目が新しく入りました）。脆弱性の名前を覚えるより、「自分のアプリのどこで起きうるか」を確かめるチェックリストとして使います。

SRE の「CVEと脆弱性管理」

今の Web アプリのコードの大部分は依存パッケージです。Dependabot（GitHub）や Renovate で更新のプルリクエストを自動で作り、pnpm audit・npm audit などで既知の脆弱性（CVE）を確かめます。ロックファイルをコミットして入る版を固定し、更新は CI のテストを通してから入れます。重大度だけで慌てず、その関数を実際に使っているかも見て優先度を決めます。

近年は、人気のパッケージの作者のアカウントが乗っ取られて悪意のある版が公開される事件が続いています。公開されたばかりの版をすぐ入れない設定（pnpm の minimumReleaseAge など）や、インストール時のスクリプトを止める設定も守りになります。

秘密情報（API キー・DB のパスワード・署名の鍵など）は、漏れると他人があなたのサービスやお金を使えてしまうものです。

フロントに置いてはいけないもの

ブラウザに送った JavaScript は誰でも読めます。ビルド時に埋め込んだ環境変数も同じです。Next.js の NEXT_PUBLIC_、Vite の VITE_ で始まる変数はバンドルに入ります。

保管と運用

• コードや Git に書かない。.env は .gitignore に入れ、本番はクラウドのシークレット管理（Secrets Manager など）や CI のシークレットに置く。
• ログやエラートラッキングに出さない（リクエストのヘッダーや本文を丸ごと記録しない）。
• GitHub の secret scanning や gitleaks などで、コミットに混ざっていないか自動で調べる。
• キーは用途ごとに分け、権限を最小にする。

ローテーションは鍵を定期的に新しくすることです。新しい鍵を発行 → アプリを新しい鍵に切り替え → 古い鍵を無効化、の順に進めると止まりません。漏れたときは、まず鍵を無効化（または入れ替え）し、その鍵で何が行われたかを利用ログで調べ、影響があれば関係者に報告します。Git の履歴から消しても、公開されていた時点で取られた前提で動きます。

アプリのコードを変えずに、レスポンスヘッダーで守りを足せるものがあります。フレームワークのミドルウェア（Helmet など）や CDN の設定でまとめて付けるのが一般的です。

HSTS は、一度付けると期限まで HTTP に戻せません。サブドメインに HTTP だけのものが残っていないか確かめてから includeSubDomains を付けます。URL に秘密（パスワード再設定のトークンなど）を入れないことも、Referrer で漏らさないための基本です。

画像や書類のアップロードは、攻撃の入口になりやすい機能です。

S3 などのオブジェクトストレージに署名付き URLで直接送らせると、アプリのサーバーが大きなファイルを受け止めずに済み、性能面でも有利です。