Service Workerの利用を把握するには？セキュリティ上の論点・確認チェックリスト・診断基準

Service Workerの利用を把握するとは

Service Workerは、Webページとネットワークの間に入る「ブラウザ内のプロキシ」として動作するJavaScriptです。一度登録されると、ページを閉じた後もブラウザに残り、登録範囲（スコープ）内のすべてのリクエストを横取りして、キャッシュから応答したり、内容を書き換えたりできます。

// トップページなどに書かれる登録コードの例
navigator.serviceWorker.register('/sw.js');

オフライン表示、プッシュ通知、表示の高速化などに使われ、自治体サイトでも防災アプリ的なPWA（Progressive Web App）化やプッシュ通知で利用されることがあります。

Service Workerの利用を把握するとは、この強力な仕組みについて、次の点を運用者が把握・管理していることを指します。

• どのスクリプトを登録しているか
• どの範囲（スコープ）に登録しているか
• どのようなキャッシュ・更新方針で動かしているか
• 侵害や障害のときにどう解除するか

セキュリティAIチェッカーのこの項目は、トップページのHTMLにService Workerの登録コードがあるかを確認し、ある場合に「スコープとキャッシュ方針を確認すべき」として△（要確認）を出します。登録が無い場合は対象外です。

Service Workerの仕様上の制約（MDN）

MDNの ServiceWorkerContainer.register() の解説によると、Service Workerには次の制約があります。仕様はW3CのService Workersで定められています。

Service Workerのセキュリティ上の論点

OWASPが挙げる指針

OWASPのHTML5 Security Cheat Sheetは、Service Workerについて次の点を挙げています。

• Service Workerを自オリジンからHTTPSで配信すること
• スコープを制限して無関係なパスを横取りしないこと
• 登録解除されるまでキャッシュ応答を返し続けるため、侵害時の「キルスイッチ」を用意すること
• 機密データをキャッシュしないこと（Cache-Control: no-store の利用）

特に注意すべき3つの点

1. 永続性：XSSなどで攻撃者が自オリジン上に任意のスクリプトを置き、Service Workerとして登録できた場合、XSSを修正した後も登録が残り、以後のページ表示を書き換え続ける可能性があります。自オリジンへのファイルアップロード機能があるサイトでは、アップロードされたJSがService Workerとして登録されないよう、アップロード先のContent-Typeや配信方法を確認します。
2. 過大なスコープ：サイトのルート（/）をスコープとするService Workerは、同じオリジン上で運用している別システム（申請フォーム、職員向け画面など）のリクエストまで横取りします。
3. キャッシュの誤り：個人情報を含む応答をキャッシュすると、共用端末で他人に表示されるおそれがあります（CWE-524「機密情報を含むキャッシュの使用」に当たります）。OWASP WSTG-CLNT-12「Browser Storage」でも、キャッシュに保存される情報の確認が求められています。

侵害時の解除手段（Clear-Site-Data）

MDNによると、Clear-Site-Data: "storage" ヘッダーは、localStorage等に加えてService Workerの登録を解除します（セキュアコンテキストのみ）。緊急時の解除手段として把握しておくと有効です。

Service Workerについてよくある誤解

• 「Service Workerを使うこと自体が脆弱性」：適切に管理されたService Workerは問題ではありません。本項目の△は「棚卸しと確認が必要」という意味です。
• 「ファイルを削除すれば止まる」：登録済みのService Workerは、更新確認でスクリプトが取得できなくなっても直ちに消えるとは限りません。新しい空のService Workerで置き換えて unregister() するか、Clear-Site-Data を使います。

なお、HTTP応答そのもののキャッシュ制御は「機密ページのキャッシュ制御」と「認証関連ページのno-store」、PWAのもう1つの構成要素であるマニフェストは「Web App Manifestの公開」の各項目で確認します。

Service Workerの利用を把握の診断基準（セキュリティAIチェッカー）

取得対象

• 診断URLへのGETで取得したトップページ（最終URL）のHTML本文（最大2MB）。
• 外部JavaScriptファイルの中身は取得しないため、登録コードが外部JSにある場合は検出できません。
• 登録されたService Workerスクリプト自体（/sw.js 等）の取得や、Service-Worker-Allowed ヘッダーの確認は行いません。

判定条件

正規表現 /serviceWorker\.register/i でHTML全体を検索します。

この項目は「利用の把握」を目的とした情報収集型の判定です。登録が確認された場合は、根拠欄の「Service Worker登録コードがあります。」をきっかけに、後述のチェックリストで運用状況を確認してください。

得点の読み方

重み1・low項目のため、△になっても総合スコアへの影響は小さく（全適用項目の重み合計が200前後の場合、変動は最大でも0.3点未満）、利用していないサイトとの差は「確認作業が残っている」ことを示すに過ぎません。確認チェックリストを満たしていても自動判定は△のままなので、報告書では「スコープ・キャッシュ方針確認済み」などの運用記録を添えて説明すると、評価の読み違いを防げます。

自治体サイトでの判定例

Service Workerを把握していないとどんなリスクがあるか

攻撃シナリオ（XSSとファイル公開機能が組み合わさった場合）

1. 公式サイトのある機能にXSSがあり、同じオリジンに利用者がファイルを置ける仕組み（添付ファイルの公開など）もある。
2. 攻撃者はJavaScriptファイルをアップロードし、XSSを使ってそのファイルをService Workerとして登録させる。
3. 以後、そのブラウザで公式サイトを開くたびに、Service Workerが応答を書き換えて偽の案内を表示する。XSS自体を修正しても、登録が残る限り影響が続く。

運用上のリスク

• スコープ / のService Workerが申請システムの応答までキャッシュし、古い画面や他人の入力結果が表示される。
• Service Worker更新時のキャッシュ設定が不適切で、修正版のスクリプトが利用者に長期間届かない。
• 委託事業者が導入したService Workerを職員が把握しておらず、障害時に原因が特定できない。

Service Workerの確認方法と安全な設定（チェックリスト・Apache・nginx・IIS・Next.js）

1. 確認チェックリスト

2. 登録コードの例（スコープ限定）

防災情報用のService Workerを /bousai/ 配下だけに限定する例です。

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/bousai/sw.js', {
    scope: '/bousai/',
    updateViaCache: 'none',
  });
}

3. スクリプトのキャッシュ制御

修正版のスクリプトが確実に届くよう、Service Workerスクリプト自体をキャッシュさせない設定にします。

Apache（.htaccess）

# Apache (.htaccess)
<Files "sw.js">
  <IfModule mod_headers.c>
    Header set Cache-Control "no-cache"
  </IfModule>
</Files>

nginx

# nginx
location = /bousai/sw.js {
  add_header Cache-Control "no-cache" always;
}

IIS（web.config）

<!-- IIS web.config（sw.jsのあるフォルダに配置。locationでsw.jsだけに限定） -->
<configuration>
  <location path="sw.js">
    <system.webServer>
      <staticContent>
        <clientCache cacheControlMode="DisableCache" />
      </staticContent>
    </system.webServer>
  </location>
</configuration>

Next.js（Vercel）

Next.js（Vercel）では next.config.js の headers() で source: '/sw.js' に Cache-Control: no-cache を設定します。

4. 緊急時の解除（キルスイッチ）

// 置き換え用の sw.js（自分自身を解除する）
self.addEventListener('install', () => self.skipWaiting());
self.addEventListener('activate', async () => {
  await self.registration.unregister();
  const clients = await self.clients.matchAll();
  clients.forEach((c) => c.navigate(c.url));
});

# 特定ページの応答で登録とストレージを消去（影響範囲が広いので緊急時のみ）
Header always set Clear-Site-Data "\"storage\""

5. 確認方法

• ブラウザの開発者ツール（Application → Service Workers）で、登録スクリプト、スコープ、状態を確認します。
• curl -sI https://www.city.example.lg.jp/bousai/sw.js でContent-Type（JavaScript）、Cache-Control、Service-Worker-Allowed の有無を確認します。

サイトを壊さないための注意点

• Clear-Site-Data: "storage" はlocalStorageやIndexedDBも消去します。ログイン状態や入力途中のデータが失われるため、常時設定せず、緊急時に限定したページで使います。
• スコープを狭めるとPWAとしてのオフライン表示範囲も狭まります。機能要件と合わせて決めてください。
• 不要になったService Workerは、ファイル削除だけでなく解除用スクリプトを一定期間配信してから撤去します。

よくある質問（FAQ）

参考資料

• MDN ServiceWorkerContainer: register() method
• MDN Using Service Workers
• MDN Clear-Site-Data
• OWASP HTML5 Security Cheat Sheet
• Microsoft Learn「Client Cache <clientCache>」
• OWASP WSTG チェックリスト

「Service Workerの利用を把握」と関連する診断項目

• 機密ページのキャッシュ制御high
• 認証関連ページのno-storehigh
• Web App Manifestの公開low
• Mixed Contentがないhigh
• WebSocketをWSSで暗号化high
• 廃止されたクライアント技術を使用していないhigh
• postMessageの送受信元を限定high
• 外部JavaScript依存数medium