PWAは安全？危険？Webサイトとの違いとセキュリティをわかりやすく解説

PWAについて調べていると、こんな疑問を持つことがあります。

「Webサイトをアプリみたいにするって、安全なの？」

ホーム画面にインストールしたり、オフラインで動いたり、Push通知を送ったりできると聞くと、普通のWebサイトより強い権限を持っているようにも感じます。

でも最初に結論を言うと、

PWAだから安全、PWAだから危険、という考え方は少し違います。

PWAはHTML、CSS、JavaScriptなど、基本的にはWebの技術で作られています。

重要なのは「PWAかどうか」ではなく、そのサイトがどんな機能を実装しているかです。

この記事では、manifest.json、Service Worker、Push通知、localStorage、Cookieなどを分けながら、PWAの安全性について整理します。

PWAは普通のWebサイトとまったく別のアプリではない

まず知っておきたいのは、PWAにした瞬間にWebサイトが突然ネイティブアプリへ変身するわけではないことです。

例えば既存のWebサイトにWeb App Manifestを追加すると、ホーム画面へ追加したときの名前やアイコン、起動方法などを指定できます。

{
 "name": "Example",
 "short_name": "Example",
 "start_url": ".",
 "display": "standalone",
 "icons": [
 {
 "src": "/icon.png",
 "sizes": "512x512",
 "type": "image/png"
 }
 ]
}

これを書いたからといって、そのWebサイトが突然スマートフォン内の写真や連絡先を自由に読み取れるようになるわけではありません。

manifest.jsonは、主にホーム画面へ追加されたときのアプリ情報をブラウザへ伝える設定ファイルです。

つまり、manifest.jsonを追加しただけでサイトの権限が増えるわけではありません。

PWAにしただけで個人情報を収集するわけでもない

これもよく混同されやすいところです。

PWAにしたからといって、自動的にユーザーの個人情報が収集されるわけではありません。

例えば、

• 名前を入力させる
• メールアドレスを保存する
• アクセス解析を入れる
• Cookieを利用する
• ログイン情報を扱う

といった処理を行うのであれば、それはそのWebサービス側の実装です。

PWAそのものが勝手に行っているわけではありません。

普通のWebサイトでも同じことはできます。

逆に、個人情報をほとんど扱わないシンプルなWebサイトをPWA化しただけなら、PWAになったことを理由に突然大量の個人情報を扱うようになるわけでもありません。

OJapp Tips｜合わせて読みたい
Webサイトを最も簡単にアプリ化する方法 | OJapp PWA Code の解説が役に立ちます。

ホーム画面に追加すると権限が増える？

ここもユーザー目線では気になるところです。

ホーム画面にアイコンが作られ、URLバーのない画面で起動すると、見た目はかなりネイティブアプリに近くなります。

そのため、

「インストールしたからスマホへのアクセス権限も増えたのでは？」

と思うかもしれません。

しかし、ホーム画面に追加したこと自体によって、サイトへ何でもできる権限が与えられるわけではありません。

カメラや位置情報、通知など、ユーザーの許可が必要なWeb APIは、それぞれの仕組みに従って扱われます。

見た目がアプリになったことと、権限が増えることは別の話です。

Service Workerは少し話が違う

PWAの安全性を考えるとき、少し注意したいのがService Workerです。

Service Workerはmanifest.jsonとは役割が大きく違います。

manifest.jsonがホーム画面での名前やアイコン、起動方法などを定義するのに対して、Service WorkerはWebページとネットワークの間に入り、通信やキャッシュを制御できます。

例えば、

ページからリクエスト
↓
Service Worker
↓
キャッシュを返す？
ネットワークへ接続する？

といった処理ができます。

これによってオフライン対応や高度なキャッシュ制御が可能になります。

便利な反面、影響範囲を理解せずに使うとトラブルを起こしやすい部分でもあります。

PWA LABではService Workerのscopeで実際にハマった

私が運営しているPWA LABでも、Service Workerの配置場所とscopeについて実機で検証しました。

例えば、

/lab/sw.js

にService Workerを置いた場合、基本的にはその階層と配下を制御できます。

/lab/
/lab/playground/
/lab/app/xxxx/

といった範囲です。

一方、

/lab/app/xxxx/sw.js

のような下の階層へ置いたService Workerから、上にある/lab/まで同じように制御することはできませんでした。

ここまでは比較的分かりやすいのですが、問題はルートです。

/sw.js

をサイトのルートへ置けば、非常に広い範囲を制御できます。

これは便利ですが、PWA LABで検証していると、

• 古いキャッシュが残る
• 別ページのキャッシュが混ざる
• 更新したコードがすぐ反映されない
• manifest周辺で想定外の挙動が起きる
• キャッシュの管理範囲が分かりにくくなる

といった問題も経験しました。

これは外部から攻撃されたという意味での「セキュリティ事故」ではありません。

Service Workerの影響範囲を広くしすぎると、自分自身で管理しにくい状態を作ってしまうという開発上のリスクです。

そのため現在のPWA LABでは、Service Workerを必要な範囲に分けて考える方が扱いやすいと感じています。

/lab/sw.js
/theme/sw.js
/editor/sw.js

のように、必要な場所だけを担当させる考え方です。

Service WorkerはPWAに必須ではない

ここで重要なのが、

PWAをホーム画面へ追加するためだけなら、Service Workerを必ず実装する必要はない

という点です。

ホーム画面への追加を目的にWeb App Manifestを使うだけなら、Service Workerを使わない軽い構成もできます。

つまり、

ホーム画面に置きたい
→ manifest

オフライン対応したい
→ Service Worker + Cache

Push通知を使いたい
→ Service Worker + Push関連の実装

と、目的に応じて必要な技術を追加すればいいのです。

Service Workerが必要ないサイトなら、無理に導入しないという選択もできます。

Push通知は勝手に送られてくる？

PWAの代表的な機能としてよく紹介されるのがPush通知です。

ここも「PWAにすると勝手に通知を送れるようになる」と考えると少し違います。

Push通知を利用するには、ユーザー側の許可が必要です。

さらにサービス側では、通知を送信するための仕組みも必要になります。

ユーザーが通知を許可
↓
購読情報を取得
↓
サービス側で管理
↓
Pushサービスを経由
↓
Service Workerが受信
↓
通知を表示

というように、manifest.jsonを追加しただけで突然Push通知が飛んでくるわけではありません。

Push通知を使わないPWAも普通に作れます。

localStorageはPWAだから危険なのではない

PWAではユーザー設定などを端末側へ保存するため、localStorageを使うことがあります。

しかしlocalStorageはPWA専用の機能ではありません。

普通のWebサイトでも使えるブラウザの保存機能です。

そのため、

「PWAはlocalStorageを使うから危険」

という考え方も正確ではありません。

重要なのは、localStorageへ何を保存するかです。

例えば、

• ダークモード設定
• チュートリアルを見たかどうか
• UIの表示設定

といった情報なら比較的扱いやすいでしょう。

一方で、漏えいすると困る重要な情報を安易に保存するのは避けるべきです。

これはPWAの問題ではなく、Webアプリ全般のデータ設計の問題です。

CookieもPWA固有の問題ではない

Cookieについても同じです。

Cookieは昔からWebサイトで使われてきた仕組みです。

ログイン状態の管理やセッション、各種Webサービスの機能に利用されています。

PWAとしてホーム画面に追加したからCookieが突然危険になるわけではありません。

Cookieの安全性は、

• 何を保存しているか
• 有効期限をどうしているか
• Secure属性などを適切に設定しているか
• 認証をどう設計しているか

といったWeb側の実装によって変わります。

ここでも「PWAかどうか」と「Webサービスのセキュリティ」は分けて考える必要があります。

HTTPSは重要

PWAに限らず、Webサービスの安全性を考えるうえでHTTPSは非常に重要です。

HTTPSではブラウザとWebサーバーの間の通信が暗号化されます。

特にService WorkerのようにWebページの通信へ関わる強力な機能は、安全なコンテキストを前提として利用されます。

つまりPWAは、何でも自由に動かせる仕組みというより、ブラウザ側のセキュリティモデルの中で動いているWebアプリです。

PWAをインストールしただけで危険になるわけではない

PWAをホーム画面にインストールしただけで、Webサイトへ特別な端末権限が与えられるわけではありません。

manifest.jsonを使ってPWAとしてインストールしたからといって、写真や連絡先、パスワードなどを自由に取得できるようになるものではありません。

注意したいのは、PWAそのものではなく、そのWebサービスが何をするかです。

例えば悪意のあるサイトが本物のサービスに似たログイン画面を表示し、そこへユーザー自身がIDやパスワードを入力すれば、情報を盗まれる可能性があります。

これは通常のWebサイトでも起こるフィッシングと基本的には同じです。

ただしPWAは、ホーム画面から standalone で起動するとブラウザのURLバーなどが表示されず、見た目がネイティブアプリに近くなります。

そのため、ログインや決済など重要な情報を入力するときは、PWAかどうかではなく、利用しているサービス自体が信頼できるものかを確認することが重要です。

結局、PWAは安全なのか？

ここまでを整理すると、答えはかなりシンプルです。

PWAだから安全でも、PWAだから危険でもありません。

例えば、Web App Manifestだけを追加してホーム画面対応したサイトと、Service Worker、Push通知、ログイン、決済、端末保存などを大量に実装したWebアプリでは、考えるべきセキュリティの範囲がまったく違います。

「PWA」という一つの言葉でまとめて危険性を判断するのではなく、実際に使っている機能を一つずつ見るのが正しい考え方です。

シンプルなPWAなら考えることも少ない

これはPWAを導入する側にとっても重要です。

例えば目的が、

「既存のWebページをホーム画面から開けるようにしたい」

だけなら、Web App Manifestを中心としたシンプルな構成にできます。

オフラインが必要なければService Workerを追加しない。

Push通知が必要なければPushの仕組みも追加しない。

端末へデータを保存する必要がなければlocalStorageも使わない。

機能が少なければ、当然管理するものも少なくなります。

PWAだから全部入りにする必要はありません。

まとめ

PWAの安全性を考えるとき、一番大切なのは「PWA」という名前だけで判断しないことです。

• manifest.jsonを追加しただけで端末への権限が増えるわけではない
• PWAにしただけで個人情報を収集するわけではない
• Push通知にはユーザー側の許可が必要
• localStorageやCookieはPWA専用の技術ではない
• Service Workerは強力なので、scopeやキャッシュ管理を理解して使う
• 必要のない機能まで実装する必要はない

つまり、PWAの安全性は、そのPWAが何をしているかで決まります。

ホーム画面に置くだけのシンプルなPWAと、決済やPush通知まで備えた本格Webアプリを同じものとして考える必要はありません。

PWAはあくまでWebの延長です。

だからこそ、必要な機能だけを選び、通常のWebサイトと同じように適切なセキュリティ設計をする。

それが一番分かりやすい答えだと思います。