PWAのセキュリティ診断方法｜プログレッシブWebアプリの安全性チェック

PWA(プログレッシブWebアプリ)は、アプリのような操作感とオフライン対応を実現できる一方で、Service WorkerやキャッシュAPIなど独自の機能により、従来のWebアプリにはないセキュリティリスクが生まれています。実際に、キャッシュポイズニングによる改ざんや認証トークンの不適切な保存など、PWA特有の脆弱性が報告されています。この記事では、PWAのセキュリティ診断で押さえるべき3つの主要リスクと、Chrome DevToolsやLighthouseを使った実践的な診断手順を解説します。

PWA特有のセキュリティリスクと診断の必要性

PWAは通常のWebアプリと異なり、Service WorkerやキャッシュAPIといった強力な機能を持つため、それらに起因する独自のセキュリティリスクが存在します。ここでは、PWA導入時に必ず把握しておくべきリスクと、診断が必要な理由を解説します。

従来のWebアプリと異なる3つのリスク

PWAには以下の3つの特有リスクがあります。

• Service Workerによるスクリプト実行リスク：バックグラウンドで動作するJavaScriptがブラウザのキャッシュやネットワーク通信を制御するため、悪意あるコードが混入すると、ユーザーの気づかないうちに通信内容を改ざん・盗聴される可能性があります。OWASP PWA Security Top 10でも、Service Workerのコード改ざんが上位リスクとして挙げられています。
• オフライン機能による機密情報の保存リスク：キャッシュAPIやIndexedDBに認証トークンや個人情報を保存する場合、暗号化が不十分だと端末紛失時に情報漏洩につながります。IPAの「安全なウェブサイトの作り方」でも、クライアント側のデータ保護が推奨されています。
• プッシュ通知の権限悪用リスク：プッシュ通知機能を悪用したフィッシング攻撃やスパム配信が発生する可能性があります。ユーザーが一度許可すると、アプリ側から自由に通知を送信できるため、悪意ある通知によるクリック誘導が懸念されます。

実際に発見されたPWAの脆弱性事例

PWA特有の脆弱性として、以下のような事例が報告されています。

キャッシュポイズニング攻撃：Service Workerがキャッシュするリソースを攻撃者が改ざんし、悪意あるスクリプトを永続的に配信し続けるケース。2019年にあるECサイトで発見され、XSS攻撃の踏み台となりました。 認証バイパス：オフライン時の認証トークン検証が不十分で、期限切れトークンでもアクセス可能だった事例。金融系PWAで報告され、セッション管理の重要性が再認識されました。 Manifest改ざん：manifest.jsonの改ざんにより、偽のアプリ名やアイコンで正規アプリに偽装するフィッシング攻撃。ユーザーがホーム画面に追加したPWAが実は攻撃者のサイトだったケースがあります。

セキュリティ診断を実施すべきタイミング

PWAのセキュリティ診断は、以下の3つのタイミングで実施することが推奨されます。

開発段階：コーディング時にセキュアコーディング基準(OWASP PWA Security Checklist等)に沿っているか確認。Service Workerのスコープ設定やキャッシュ対象の見直しを行います。 本番公開前：LighthouseやChrome DevToolsを使った自動診断で、HTTPS化・CSP設定・認証フロー等を総合的にチェック。脆弱性診断ツールによるペネトレーションテストも有効です。 定期診断(年1-2回)：Service Workerの更新やライブラリのバージョンアップ後は、新たな脆弱性が混入する可能性があるため、定期的な再診断が必要です。

PWAセキュリティ診断の4つの柱

PWAのセキュリティ診断では、以下の4つの観点から総合的にチェックする必要があります。それぞれの診断項目と具体的な確認方法を解説します。

HTTPS通信とSSL/TLS設定の検証

PWAはHTTPS必須であり、これが満たされていない場合はService Workerが動作しません。しかし、HTTPS化されていても、証明書の設定不備や古い暗号化方式の使用により、中間者攻撃のリスクが残ります。

証明書の有効性確認：Chrome DevToolsの「Security」タブで、証明書の発行元・有効期限・証明書チェーンを確認します。自己署名証明書や期限切れ証明書は使用不可です。 TLSバージョンと暗号スイート：TLS1.2以上を使用し、弱い暗号化方式(DES、RC4等)が無効化されているか確認。SSL Labs等のオンラインツールで「A」評価以上を目指します。 HSTSヘッダーの設定：HTTPSへの強制リダイレクトだけでなく、Strict-Transport-Securityヘッダーを設定し、ブラウザに常時HTTPS接続を強制させます。

Service Workerのスクリプト検証

Service Workerはブラウザとネットワーク間の通信を制御できるため、悪意あるコードが混入すると甚大な被害が発生します。

XSS対策の確認：Service Workerスクリプト内で外部入力をそのまま使用していないか確認。動的にコードを生成する場合は、eval()やFunction()の使用を避け、サニタイジング処理を徹底します。 コード改ざん検証：Service WorkerファイルのSRI(Subresource Integrity)ハッシュ値を検証し、配信時に改ざんされていないか確認。CDN経由で配信する場合は特に重要です。 スコープ設定の妥当性：Service Workerのscopeが必要以上に広範囲でないか確認。例えば、/配下全体ではなく、/app/配下のみに限定するなど、最小権限の原則を適用します。

キャッシュストレージとオフライン機能の安全性確認

PWAはオフライン対応のため、キャッシュAPIやIndexedDBに多くのデータを保存します。ここに機密情報が含まれると、端末紛失時の情報漏洩リスクが高まります。

機密情報保存の有無：Chrome DevToolsの「Application」タブ→「Cache Storage」「IndexedDB」で、認証トークン・個人情報・決済情報が平文で保存されていないか確認します。 キャッシュ有効期限の設定：古いキャッシュが残り続けないよう、Cache-Controlヘッダーでmax-ageを適切に設定。機密性の高いページはno-storeを指定してキャッシュを無効化します。 オフライン時の認証フロー：オフライン時も認証トークンの有効期限を検証し、期限切れの場合はオンライン復帰時に再認証を促す設計になっているか確認します。

Manifestファイルとプッシュ通知のセキュリティ設定

manifest.jsonはPWAの設定ファイルであり、アプリ名・アイコン・権限スコープなどを定義します。不適切な設定は、フィッシングやなりすましのリスクを生みます。

start_urlとscopeの検証：start_urlが意図したURLであり、scopeが適切に制限されているか確認。攻撃者がmanifestを改ざんして別サイトへ誘導するケースがあります。 アイコンとアプリ名の整合性：icons配列に指定された画像が正規のものか、短縮名(short_name)が正式名称と一致しているか確認。偽アプリと誤認されるリスクを防ぎます。 プッシュ通知権限の管理：通知許可リクエストのタイミングと頻度を適切に設計し、ユーザーの意図しない許可を防ぎます。また、通知内容にユーザー固有の機密情報を含めない設計を推奨します。

実践的なPWAセキュリティ診断手順

ここでは、実際にPWAのセキュリティ診断を行う際の具体的な手順とツールの使い方を解説します。技術的な知識がある方であれば、社内でも基本的な診断が可能です。

Chrome DevToolsを使った診断方法

Chrome DevToolsは、PWA診断において最も手軽で強力なツールです。以下の手順で診断を進めます。

Applicationタブの確認：「Application」タブを開き、「Service Workers」でスクリプトの登録状況・スコープ・更新履歴を確認。「Unregister」ボタンで一度解除し、再登録時にエラーが出ないか検証します。 Securityタブでの証明書検証：「Security」タブで、TLSバージョン・証明書の有効性・Mixed Contentの有無を確認。警告が表示される場合は、HTTPSリソースへの置き換えが必要です。 Networkタブでの通信監視：「Network」タブで、Service Workerがキャッシュから応答しているか、それとも実際にネットワーク通信が発生しているかを確認。「Offline」チェックボックスでオフライン動作をテストします。 Consoleでのエラー確認：Service Worker登録時やfetchイベント処理時にエラーが出ていないか確認。CSP違反やCORS エラーは脆弱性の兆候となることがあります。

Lighthouseでの自動診断と評価

Lighthouseは、PWAの品質とセキュリティを自動で診断できるツールです。Chrome DevToolsに統合されており、手軽に利用できます。

PWA項目のスコア確認：「Lighthouse」タブで「Progressive Web App」にチェックを入れて診断実行。HTTPSリダイレクト・Service Worker登録・manifest.json設定などが自動評価されます。 セキュリティ項目の詳細確認：診断結果の「Security」セクションで、HTTPS・CSP・Mixed Content・脆弱なライブラリの検出結果を確認。各項目に改善提案が表示されます。 Best Practicesの遵守状況：「Best Practices」項目で、XSS対策・CORS設定・ブラウザエラーの有無をチェック。スコア90点以上を目標とします。

OWASPガイドラインに基づくチェック

OWASP(Open Web Application Security Project)は、PWA特有のセキュリティリスクをまとめた「PWA Security Top 10」を公開しています。これに基づいた診断が推奨されます。

Service Workerのインジェクション攻撃対策：外部から制御可能なパラメータでService Workerのキャッシュ先を動的に変更していないか確認。攻撃者による任意のリソースキャッシュを防ぎます。 認証・認可の実装確認：オフライン時も含め、すべてのAPIリクエストで有効なトークン検証が行われているか確認。JWTの署名検証とペイロードの改ざん検知が必須です。 CSP(Content Security Policy)の設定：HTTPヘッダーまたはmetaタグでCSPを設定し、インラインスクリプトの実行制限・外部リソース読み込み制限を実施。Service Workerスクリプトもnonce検証を推奨します。

外部ツールとペネトレーションテスト

より高度な診断を行う場合は、以下のツールや専門家による診断が有効です。

Burp Suiteによる通信解析：プロキシツールのBurp Suiteを使い、Service Workerが介在する通信の内容を詳細に解析。改ざんやリプレイ攻撃の可能性を検証します。 OWASPZAPによる自動スキャン：オープンソースの脆弱性診断ツールOWASPZAPで、SQLインジェクション・XSS・認証バイパス等を自動検出。PWA特有の項目も追加設定で診断可能です。 外部専門家によるペネトレーションテスト：金融系やヘルスケア系など機密性の高いPWAでは、セキュリティ専門企業による実際の攻撃シミュレーションを実施することが推奨されます。社内診断では発見できない高度な脆弱性が見つかるケースがあります。

PWAセキュリティ診断で見落としやすいポイント

PWA診断では、一般的なWebアプリ診断では見落としがちな独自のチェックポイントがあります。ここでは特に注意すべき3つの観点を解説します。

オフライン時の認証情報管理

PWAの最大の特徴であるオフライン対応ですが、ここに認証の盲点が潜んでいます。

トークン有効期限の厳密な管理：オフライン時にキャッシュされた認証トークンが、有効期限切れでも使用できる設計になっていないか確認。JWTのexpクレームを検証し、期限切れの場合はオンライン復帰時に再認証を強制します。 オフライン操作の同期戦略：オフライン時に行われた操作(データ編集・削除等)をオンライン復帰時に同期する際、認証状態の再確認が行われているか検証。攻撃者が意図的にオフライン状態を作り出し、期限切れトークンで操作を試みるケースがあります。 リフレッシュトークンの保存場所：長期間有効なリフレッシュトークンをIndexedDBに保存している場合、XSS攻撃で盗まれるリスクがあります。可能であればHttpOnlyクッキーでの管理を推奨します。

プッシュ通知の権限管理と悪用リスク

プッシュ通知は利便性が高い一方、ユーザー体験を損なう悪用リスクも存在します。

通知許可リクエストのタイミング：ページ読み込み直後にいきなり通知許可を求める設計は、ユーザーが内容を理解せずに許可してしまうリスクがあります。サービス利用の文脈で必要性を説明した上でリクエストする設計を推奨します。 通知内容の機密性：プッシュ通知に個人情報や機密情報を含めると、端末ロック画面で第三者に閲覧されるリスクがあります。「新着メッセージがあります」程度の抽象的な内容にとどめ、詳細はアプリ内で確認させる設計が安全です。 通知配信の頻度制限：過度な通知はスパムと見なされ、ブランドイメージを損ないます。ユーザーが通知頻度を設定できる機能や、1日あたりの配信上限を設けるなどの配慮が必要です。

Service Worker更新時の脆弱性

Service Workerは一度登録されると、意図的に更新しない限り古いバージョンが動作し続けるため、更新管理が重要です。

古いバージョンの残存リスク：Service Workerファイルを更新しても、ユーザーのブラウザが古いバージョンをキャッシュしている場合があります。Cache-Controlヘッダーでno-cacheを設定し、毎回サーバーに更新確認させる設計が推奨されます。 更新時の認証確認：Service Worker更新時にも、正規のサーバーから配信されているか検証する仕組みが必要です。中間者攻撃で偽のService Workerに差し替えられるリスクを防ぎます。 破壊的な更新への対応：新しいService Workerが古いキャッシュと互換性がない場合、エラーが発生する可能性があります。バージョン管理を徹底し、古いキャッシュを適切にクリアする処理を実装します。

まとめ

この記事では、PWAのセキュリティ診断について解説しました。重要なポイントは以下の3つです。

PWA特有の3つのリスクを理解する：Service Worker・オフライン機能・プッシュ通知には、通常のWebアプリにない独自のセキュリティリスクが存在します。 4つの柱で総合的に診断する：HTTPS設定・Service Workerスクリプト・キャッシュストレージ・Manifestファイルの4つの観点から、Chrome DevToolsやLighthouseを活用して診断を実施します。 見落としやすいポイントに注意する：オフライン時の認証管理・プッシュ通知の悪用リスク・Service Worker更新時の脆弱性など、PWA特有の盲点を押さえた診断が必要です。

PWAは適切なセキュリティ対策を実施すれば、安全で利便性の高いアプリとして運用できます。まずはChrome DevToolsでの基本診断から始め、必要に応じて外部専門家によるペネトレーションテストを検討することをおすすめします。定期的な診断とOWASPガイドラインに沿ったチェックで、安全なPWA運用を実現しましょう。