Experience Cloudゲストユーザー保護の決定版：今すぐ実行すべき9つのアクション

2026年5月現在、企業が運営する外部公開Experience Cloudサイトにおいて、未認証のゲストユーザー権限の不備を標的としたデータ抽出インシデントが継続して報告されています。

Salesforceプラットフォーム側では過去数年にわたり厳格なセキュリティ強化が実施されてきましたが、それでもなおインシデントが根絶されない背景には、現場の開発・運用プロセスにおける「設定の複雑さ」と「セキュリティ意識のギャップ」が存在します。
そして2026年3月11日、継続的な調査結果に基づき、管理者が直ちに取るべき「9つの必須アクション」を公開しました。

本記事では、過去のセキュリティ強化の経緯を振り返りつつ、最新の推奨事項と、現場で特に注意すべき実装上のジレンマについて解説します。

ゲストユーザーセキュリティの歴史的背景
いまだに設定不備による情報漏洩が後を絶たない理由
公式ブログに基づく「今すぐ実行すべき9つのアクション」
LWRサイトにおける「API無効化」のジレンマ
1. LWRでの仕様上の制約
2. 現場での回避策
【まとめ】安全に監査・修正を進めるためのステップ
参考URL

ゲストユーザーセキュリティの歴史的背景

Salesforceは、ゲストユーザーによる意図しないデータアクセスを防ぐため、プラットフォームの基本仕様を段階的に変更してきました。現在のセキュリティモデルの前提となる重要な仕様は以下の通りです。

アクセス権限の厳格化（Spring ’21）: ゲストユーザープロファイルから「すべて表示」「すべて変更」「編集」「削除」権限が完全に廃止されました。標準機能としてのアクセスは「参照」または「作成」のみに制限されています。
ゲストユーザー共有ルールの導入: 組織の共有設定（OWD）に関わらず、ゲストユーザーに既存レコードへのアクセスを許可する場合は、専用の「ゲストユーザー共有ルール」による条件ベースの共有が必須となりました。
責任共有モデル: Salesforceはインフラ環境のセキュリティを提供しますが、プラットフォーム上で「どのオブジェクト・項目に、どのような権限を付与するか」は顧客側の責任範囲となります。

しかし、プラットフォーム側で入り口を狭めても、管理者による設定の不備や、カスタム実装（Apex）における不適切なデータ取得ロジックが残っている場合、それらが標的となります。

近年のインシデントは、プラットフォームの未知の脆弱性を突かれたものではなく、Auraエンドポイントなどを通じて「顧客側が過剰に付与してしまった権限」がそのまま悪用されている状態です。

いまだに設定不備による情報漏洩が後を絶たない理由

強固なデフォルトセキュリティが提供されているにもかかわらず、現場の実運用において設定不備が生じ、それが放置されてしまう理由として以下の課題が推測されます。

「とりあえず動かす」アプローチによる過剰権限
開発中、UIコンポーネントをゲストユーザーに表示する際に権限エラーが頻発することがあります。スケジュールの都合上、エラーの根本原因を特定して最小権限を設計するのではなく、「APIを有効化する」「オブジェクトの参照権限を広く開ける」といった安易な回避策が取られ、そのまま本番リリースされるケースが散見されます。
「UIに表示しなければ安全」という誤認
「画面上のコンポーネントに項目を表示していなければ、ゲストユーザーには見えない」という認識は誤りです。攻撃者はブラウザの開発者ツールなどを利用し、バックグラウンドのエンドポイントへ直接APIリクエストを送信します。項目レベルセキュリティ（FLS）が制限されていなければ、裏側のデータは容易に抽出されます。
Apexにおける without sharing の乱用
標準の共有ルールが厳格化された結果、複雑な要件を満たすためにApexを使用するケースが増加しています。その際、レコードアクセス制御を回避する目的で without sharing を乱用すると、プラットフォームのセキュリティモデルをバイパスするカスタムAPIが意図せず公開状態になってしまいます。

公式ブログに基づく「今すぐ実行すべき9つのアクション」

これらのリスクを防ぐため、Salesforce公式ブログにて直ちに行うべきアクションとして以下が推奨されています。

ゲストユーザー構成の監査
現在のプロファイルおよび権限セットの割り当てを再確認する。
共有設定（OWD）の非公開化
すべてのオブジェクトの「デフォルトの外部アクセス権」を非公開に設定する。
パブリックAPIへのアクセス無効化
サイト設定の「パブリック API へのアクセス許可」およびプロファイルの「API の有効化」をオフにする（※LWRサイトでは注意が必要。後述）。
可視性の制限
「ポータルユーザーの表示」および「サイトユーザーの表示」をオフにする。
不要な自己登録の無効化
自己登録機能（Self-Registration）を使用していない場合は無効にする。
拡張個人情報マスキング (EPIM) の確認
ユーザーレコードの機密項目が適切に保護されているか、EPIMの設定をレビューする。
プロファイルフィルタリングの有効化
ユーザーが他のユーザープロファイルを参照できる範囲を制限する。
ニックネーム表示の有効化
サイト上で本名の代わりにニックネームを表示する設定を強制する。
非ユーザーオブジェクトの項目レベルセキュリティ (FLS) 監査
取引先や連絡先など、ユーザー以外のオブジェクトの各項目への参照権限を最小限に絞り込む。

LWRサイトにおける「API無効化」のジレンマ

アクション3の「パブリックAPIへのアクセス無効化」については、LWR（Lightning Web Runtime）サイトを運用している場合にクリティカルな影響が出ます。

LWRでの仕様上の制約

LWRアーキテクチャでは、ナビゲーションメニューやCMSコンテンツなどの標準コンポーネントが、User Interface APIを利用して動的に描画される仕様です。公式ドキュメントでも、これらを表示するためには「パブリック API へのアクセス許可」を有効にすることが求められています。

【LWRトラブルシュート】ゲストユーザーにナビゲーションメニューが表示されない！？原因は「あのチェックボックス」でした

LWRサイトでゲストユーザーにナビゲーションメニューが表示されない問題の解決法。[管理] > [詳細] の「公開 API へのゲストユーザーのアクセスを許可」を有効にする手順を解説。

現場での回避策

LWRサイトにおいてアクション3をそのまま適用すると、ナビゲーションメニューが消えるなどの機能不全が発生します。この場合、APIを「ON」にしたまま、以下の対策に注力するのが現実的なアプローチです。

プロファイルとFLSの徹底した削ぎ落とし
APIが開いていても、ゲストユーザーがオブジェクトや項目への参照権限（FLS）を持っていなければ、実データは抽出されません。
Apexクラスの再監査
独自のコンポーネントで使用しているApexクラスが with sharing で適切にレコードアクセスを制限しているか、全量レビューを実施します。

【まとめ】安全に監査・修正を進めるためのステップ

稼働中のサイトに対して設定変更を行う際は、以下の手順を推奨します。

Sandboxでの入念なテスト
特にアクション3の設定変更は、LWRサイトにおいてはナビゲーションメニューの消失を招くため、Sandboxでの入念な回帰テストが不可欠です。
リリース後のモニタリング
設定変更後はデバッグログやイベントモニタリングを活用し、正当なユーザーによるアクセスが「Insufficient Privileges」で拒否されていないかを確認します。

セキュリティは「一度設定したら完了」ではありません。最新の脅威動向に合わせて、定期的にゲストユーザーの権限セットを監査するプロセスを運用フローに組み込むことが、最大の防御となります。