これは、筆者の「2025振り返り用ひとりアドカレ」記事の一つです。
はじめに
本記事は、フロントエンドに携わっている筆者がwebセキュリティを学習した際にメモ書きしていたものを体系的にまとめ直した内容です。
かなり長くなったので7記事のシリーズとして投稿していきます。
これまでの開発において、エスケープ処理やサニタイズ、アクセス制御などセキュリティを意識して行ってきましたが、そもそも「どういった経緯で、どうなる（なってしまう）から、どのような対策が必要となるか」を深く理解できていない自覚がありました。
そこで【フロントエンド開発のためのセキュリティ入門 知らなかったでは済まされない脆弱性対策の必須知識】をベースに生成AIも使いながらインプットしていきました。
もちろん今でもまだまだだと思っていますし、本記事は備忘録の側面が強いかもしれませんが、初学者をはじめ、筆者のようにセキュリティ対策の重要性は理解しているがどこか表層的な部分に留まっているかもというような方々に少しでも役立つように書いていきたいと思います。
シリーズ目次
- 第1回：Web通信の基礎知識
- 第2回：オリジンとCORS
- 第3回：サイドチャネル攻撃とSite Isolation（本記事）
- 第4回：XSS（クロスサイトスクリプティング）
- 第5回：CSP（Content Security Policy）
- 第6回：CSRF、クリックジャッキング、その他の攻撃
- 第7回：認証・認可とセキュアな実装
前回が長かったので今回はボリューム量を調整して文章量が少なめです。
サイドチャネル攻撃
サイドチャネル攻撃とは、本来アクセスできない機密情報を、CPUのキャッシュ挙動・実行時間・電力消費・メモリアクセスパターン、ハードウェアの特性などの「副次的な情報（サイドチャネル）」から推測する攻撃手法を指します。
近年では、CPUの投機実行やキャッシュ機構を悪用した攻撃が特に有名です。
サイドチャネル攻撃を防ぐ Site Isolation
Site Isolation とは、境界（サイト）ごとにプロセスを分離する仕組みのことです。
プログラムの中には他のプログラムのデータへアクセスできるものもあって、ケースによっては危険な状況にもなります。
一般的に、OSは「プロセス」という単位でプログラムの処理を管理していて、メモリ領域をプロセスごとに隔離しています。
これによって、プロセスをまたいだメモリへのアクセスはできないようになっています。
ブラウザは、内部で Webアプリケーションごとではなく、「サイト（eTLD+1）単位」でプロセスを分離することでサイドチャネル攻撃を防いでいます。
例えば、レンダリング（描画）プロセスを各サンドボックス内に入れて個別管理し、それらサンドボックスの各種処理を全体包括する形でブラウザプロセスが成り立っています。
- 注釈
サンドボックスは文字通り「砂場」というニュアンスで、意味するところは「その中だと外部に影響を及ぼさずに自由にできる（遊べる）よ」というイメージです。
つまり、公園の中にある複数の砂場でプロセス（プログラムの処理）が実施されていて、それぞれの砂場での処理を全体管理するのが公園（ブラウザ）というのが緩いイメージ説明です。
ここでいう個別管理がプロセスの隔離にあたり、これは「境界（サイト）」という単位で実施されます。
このサイトは、webサイトのそれとは異なり「オリジンと異なる定義を持ったセキュリティのための境界（サイト）」という意味です。
サイトの定義は「eTLD+1」と決まっていて、eTLD（トップレベルドメイン）とは.com,.jp,.co.jp といったドメインを含みます。
Site Isolation によって制限されてしまった機能の有効化
Site Isolation によってサイドチャネル攻撃の大部分を防ぐことができますが、その代わりにいくつかのAPIや機能が無効化されてしまいます。
これら制限された機能を有効にするには、オリジンごとにプロセスを分けてサイドチャネル攻撃が発生しないことを保障せねばなりません。
それを実現するのが、Cross-Origin Isolation です。
これは、後述の COOP と COEP を同時に正しく設定することで成立し、「ページがより強く隔離された実行環境」のことを指します。
Cross-Origin Isolation が成立すると、通常はサイト単位で行われているプロセス分離が実質的にオリジン単位レベルの強度まで引き上げられます。
CORP, COEP, COOP
以下の3つの仕組みを有効化（レスポンスヘッダに設定）することで、Site Isolation によって制限された機能を扱えるようになります。
Cross-Origin Resource Policy（CORP）
- リソースの読み込み制御
他のオリジンからのリソース読み込みを制限するポリシー
Cross-Origin Embedder Policy（COEP）
- 埋め込みリソースの制御
ページに埋め込まれるすべてのリソースに対してCORSまたはCORPの明示的な許可（設定強制）を要求
Cross-Origin Opener Policy（COOP）
- ウィンドウ間の情報漏洩を防止
新しいタブやウィンドウを開いた際の相互アクセスを制限する
とはいえ、前述の通りオリジンごとにプロセスを分けてレスポンスヘッダに各種設定をしていく必要があるので、これは所属企業や組織、チームの開発方針やトレードオフを加味して実施するのが現実的なように感じます。
さいごに
ここまで読んでいただき、ありがとうございました。
筆者の知識・経験不足から間違った点や、誤解を招きかねない表現がありましたらご教示・ご指摘いただけますとありがたい限りです。