前回からのつづき

前回、 OPFS について、IndexedDB との比較を交え、基本的な使い方まで説明を行ってきました。今回は、その続きとして、OPFS に対する誤解や、セキュリティについてまとめていきたいと思います。

よくある勘違い（ CORS との関係）

CORS（Cross-Origin Resource Sharing）は、「この Web API は、どのサイトからのアクセスを許可するか？」をサーバー側がブラウザに伝える仕組みです。詳細については、過去記事、「モダンJavaScript入門/fetch API（XHR からの進化）」を参照してください。

OPFS 自体はローカルストレージ機能であり、CORS の対象ではありません。

例えば、

const root =　await navigator.storage.getDirectory();

のような操作では、CORS 設定は不要です。

ただし、外部サーバーからデータを取得する場合は通常どおり CORS 制約を受けます。

const response =　await fetch("https://api.example.com/data.json");

この時点で CORS チェックが行われます。

取得したデータを OPFS へ保存すること自体には制限はありません。

つまり、

外部サーバー
 ↓
fetch
 ↓
CORSチェック
 ↓
OPFSへ保存

という流れになります。

👉 OPFS が CORS の対象なのではなく、データ取得時の通信が CORS の対象になります。

実践的な使い方

実際のアプリでは、IndexedDB や　SQLite WASM　と組み合わせて利用するケースが多くあります。

例えば画像管理アプリなら、

IndexedDB or SQLite WASM
 ├─ id
 ├─ fileName
 ├─ createdAt
 └─ tags

OPFS
 ├─ image001.jpg
 ├─ image002.jpg
 ├─ image003.jpg
 └─ app.db

のような構成になります。

検索やメタ情報管理は IndexedDB または SQLite WASM

実ファイルは OPFS

それぞれの得意分野を活かす構成です。

👉 この構成の利点は、OPFS に検索機能を付加することができることです。

OPFS のセキュリティ

OPFS はブラウザが提供するプライベートなファイルシステムですが、必ずしも万能なセキュリティ機能ではありません。

安全に利用するためには、OPFS の強みと弱みを理解しておくことが重要です。

【強い点】

■ 同一オリジン制約によって保護される

OPFS はブラウザの同一オリジンポリシー（ Same-Origin Policy ）によって保護されています。

例えば、

https://example.com

で保存されたデータは、

https://sample.com

や

https://sub.example.com

など、別オリジンの Web サイトからアクセスすることはできません。

これは Cookie や IndexedDB などと同様です。

そのため、別サイトから勝手に OPFS 内のデータを読み取られる心配はありません。

【弱い点（重要）】

■ JavaScript から自由にアクセスできる

OPFS は JavaScript から自由にアクセスできることが大きな特徴です。

しかし、これは同時にリスクでもあります。

Web アプリケーション上で実行される JavaScript は、通常の API を利用して OPFS 内のデータを読み書きできます。

つまり、

正規のアプリ
↓
OPFS へアクセス可能

悪意のある JavaScript
↓
OPFS へアクセス可能

ということです。

■ XSS があると全データを取得される

OPFS 最大のリスクは、XSS（ Cross Site Scripting ）です。

アプリケーションに XSS 脆弱性が存在すると、攻撃者が任意の JavaScriptを 実行できる可能性があります。

その結果、

  • OPFS 内のファイル一覧取得
  • ファイル内容の読み取り
  • データの外部送信
  • ファイルの削除や改ざん

などが行われる恐れがあります。

つまり、

XSS 成立
 ↓
悪意のある JavaScript 実行
 ↓
OPFS へアクセス
 ↓
データ漏洩

という流れです。

OPFS は外部サイトから保護されていますが、同一オリジン上で実行される JavaScript からは保護されません。

そのため、XSS 対策が最も重要なセキュリティ対策になります。

実務で必要なセキュリティ対策

■ HTTPS を使用する

OPFS はセキュアコンテキストでのみ利用できます。そのため、本番環境では HTTPS を使用することが前提となります。

通信経路の盗聴や改ざんを防ぐためにも、HTTPS は必須です。

■ CSP（ Content Security Policy ）を設定する

CSP（ Content Security Policy ）は、ブラウザに対して「どのスクリプトの実行を許可するか」を指示する仕組みです。

適切に設定することで、XSS 攻撃の成功率を大きく下げることができます。

例えば、JavaScriptファイルの読み込み元を同一オリジンに制限する

Content-Security-Policy:
  default-src 'self';
  script-src 'self';

のような設定が利用されます。

■ コードの XSS 対策を徹底する

最も重要なのは、アプリケーション自体に XSS 脆弱性を作らないことです。

例えば、

  • ユーザー入力を適切にエスケープする
  • innerHTML の使用を避ける
  • 信頼できない HTML を直接挿入しない
  • ライブラリやフレームワークの推奨方法を利用する

といった対策が必要です。

XSS 脆弱性が存在すると、 OPFS 内のデータがすべて取得・改ざんされる可能性があります。

そのため、実務では「 OPFS の保護」ではなく、「 JavaScript を安全に実行させること」が最も重要な対策となります。

■ 機密情報は、アプリケーション側で暗号化

OPFSはアクセス制御の仕組みであって、機密情報を自動的に暗号化してくれる仕組みではありません。そのため、機密情報を保存する場合は、アプリケーション側で暗号化を検討する必要があります。

まとめ

  • OPFS はブラウザ内のプライベートファイルシステム
  • 大容量データとの相性が良い
  • IndexedDB や SQLite WASM と組み合わせると実践的
  • 利用上の注意点
    • オリジンごとに独立して管理される。
    • HTTPS 環境が必要（localhostは例外）
    • ユーザーは直接アクセスできない。
    • ブラウザごとに容量制限がある。
    • Sync Access Handle 利用時は追加ヘッダーが必要な場合がある。
    • OPFS 自体は CORS の対象ではない。
    • OPFS には特別なセキュリティ上の制限や暗号化の仕組みはない。
    • OPFS は下記の対策を実施することで、初めて安全に利用できる。
      • 同一オリジン制約による保護
      • HTTPS
      • CSP
      • XSS対策

👉 OPFS は IndexedDB の代替ではなく、ファイル管理を得意とする補完的な技術です。