BFFが外部公開面になりやすい理由とは？確認ポイントと対策

BFFはなぜ外部公開面になりやすいのか

トークンをブラウザへ置かないことと、公開面が消えることは別です

BFF の価値は、ブラウザアプリのトークン処理を改善できることにあります。IETF のブラウザアプリ向け文書でも、トークンをブラウザへ長く持たせる方式には制約があり、代替の一つとして BFF 型が議論されています。ただし、これはトークンをブラウザから遠ざけるのであって、BFF の公開経路が外部公開面でなくなることを意味しません。

むしろ BFF を入れると、ユーザーのブラウザは BFF へ継続的にリクエストを送るようになります。つまり BFF 自体が外から叩かれる APIです。ここを「内部サービスに近い」と誤解すると、認可、CSRF、セッション Cookie、CORS、デバッグ用経路の確認が薄くなります。BFF を安全設計と同一視しないことが第一歩です。

Azure Architecture Center の BFF パターンも、BFF を画面ごとに最適化したバックエンドとして説明しています。これは裏を返すと、BFF は画面ごとの要求に応答する公開窓口であり、フロントエンドに近い層だからこそ公開境界にいるということです。裏側の構成要素という言い方だけで、公開面の棚卸しから外してはいけません。

BFFの誤解は「フロントエンドの画面制御で守れる」と思うところから始まります

BFF の設計で起きやすい誤解は、フロントエンドの画面制御があるから危険な操作は表に出ない、と考えることです。しかし OWASP API Security Top 10 2023 が示すように、公開 API ではオブジェクト単位の認可や機能単位の認可が独立した論点になります。画面にボタンがないことと、API が拒否することは別です。

BFF はフロントエンド向けにパスを整形し、複数 API を集約するため、画面の都合で経路が増えやすくなります。その結果、古い経路、管理用経路、デバッグ用経路が残りやすく、気付かないうちに外部から叩けるパスが増えます。バックエンド・フォー・フロントエンドという構成は画面の裏側であって、閉域の裏側ではありません。この前提を外さないことが重要です。

何を確認すべきか

ブラウザ境界の保護は BFF 導入後も独立して必要です

BFF を入れるとトークンをサーバー側へ寄せやすくなりますが、ブラウザと BFF の間にはセッション Cookie やリダイレクトが残ります。したがって、CSRF、SameSite、secure 属性、ログアウト時のセッション廃棄、オリジン制御といったブラウザ境界の保護は依然として重要です。トークンを隠しただけでブラウザ操作の攻撃面は消えません。

ここで見落としやすいのは、フロントエンドが別オリジン、プレビュー用オリジン、モバイルアプリ用オリジンを持つケースです。BFF のホスト名が一つでも、呼び出し元オリジンが増えると制御面は複雑になります。安全性は BFF という名前ではなく、どのオリジンから何を許すかを明示できているかで決まります。

下流 API へのトークンと認可を縮めないと、BFF は単なる中継になります

BFF から下流 API へ渡すトークンの権限範囲が広すぎる、またはサービスアカウントが過剰権限のままだと、BFF を通した意味が薄くなります。RFC 9700 が示す OAuth 2.0 Security BCP の観点でも、トークンの権限と利用文脈は最小化すべきです。BFF を入れたのに下流トークンが広いままなら、侵害時の被害範囲は大きく残ります。

また、BFF では集約の都合で複数のバックエンド呼び出しを一つの経路にまとめることがあります。便利ですが、この経路に対してオブジェクト単位・機能単位の認可を十分に掛けていないと、画面では見えないデータや操作が API では呼べる状態を作ります。これは既存のシャドーAPIのリスクやフロントエンドのAPIキー露出とも接続する論点です。

どう運用へ落とすべきか

BFF を API 台帳と外部確認の両方へ載せます

BFF を安全に使うには、構成図の中だけで扱わず、API 台帳と外部公開面台帳の両方へ載せる必要があります。開発チームの設計資料には載っていても、外部公開面の棚卸しに入っていないと、ゲートウェイ裏のオリジン側ホスト名や古い経路が見落とされます。

既存のMFA例外アカウントのリスクと同じで、BFF も「本来は厳しく管理される前提」の仕組みです。前提が崩れたときに危険になるので、定常運用では棚卸し対象として残すこと自体が重要です。内部設計の一要素としてだけ扱うと、公開経路が台帳から落ちます。

エッジの後ろにあるオリジンと管理経路を別途確認します

実務で特に危ないのは、「公開はゲートウェイ配下だけ」と思っているのに、オリジン側ホスト名や管理用 API が別経路で応答しているケースです。BFF はフロントエンドと近いぶん、プレビュー用ホスト名や開発用ホスト名がそのまま残りやすく、しかもその経路がゲートウェイの統制外にあることがあります。正面の入口だけでなく、裏口の入口も外から見る必要があります。

BFF の公開残存は、構成図ではなく実際の応答で見つける方が早いです。ホスト名がまだ解決するか、証明書が生きているか、管理経路が 401/403 ではなく別応答を返していないか、古いパスがまだ通るかを確認してください。BFF は『安全な設計パターン』であって、安全が自動的に維持される製品ではありません。

BFFで起きやすい設計ミス

画面統合と認可統合を同じものとして扱うと危険です

BFF を入れると、フロントエンド側の呼び出し先が整理され、画面から見た構成はすっきりします。しかし、画面が一つにまとまることと、認可の論点が減ることは同じではありません。BFF は複数の下流 API をまとめるぶん、一つの公開経路の裏で複数の権限判断が走ることがあります。ここを「BFF 側で吸収しているから大丈夫」と考えると、画面に見えないデータや操作の認可が抜けやすくなります。

典型的なのは、一覧画面と詳細画面を同じ BFF 経路で返しているのに、画面側の表示分岐だけでアクセス制御したつもりになるケースです。BFF が内部で複数 API を呼び出しているなら、その呼び出しごとに必要な権限と返却データの境界を確認しなければなりません。「画面に出さない」ことは「返さない」ことの代わりにはなりません。BFF は画面実装を楽にしますが、API の認可を簡単にはしてくれません。

ブラウザ境界を軽く見ると、BFF 導入後でも攻撃面が残ります

BFF を採用した後に起きやすいもう一つの誤解は、「トークンをブラウザへ置かなくなったので、ブラウザ側の論点はかなり減った」と考えることです。実際には、セッション Cookie、CSRF、オリジン制御、ログアウト時の廃棄、リダイレクト URI など、ブラウザと BFF の間で守るべき境界はそのまま残ります。とくに複数のフロントエンド、プレビュー環境、モバイル向け導線が並ぶと、呼び出し元オリジンの管理が BFF 導入前より難しくなることも珍しくありません。

さらに、BFF ではログイン中のセッションを前提にする経路が増えやすく、古いプレビュー用ホスト名や検証用経路が残ると、想定外の呼び出し面が広がります。セッション Cookie の属性や CORS 設定だけでなく、「このホスト名からこの経路を呼んでよいか」という観点まで含めて見直さないと、トークンは隠せていても操作面は開いたままという状態になりかねません。

下流 API 向けの権限を縮めないと、中継層の価値が薄れます

BFF の下でよく起きるのが、フロントエンド向けには入口を整理したものの、下流 API へ渡すトークンやサービスアカウントの権限が広いまま残るケースです。BFF が複数 API を束ねると、実装上は一つの資格情報でまとめたくなりますが、そこで権限縮小を諦めると、BFF は単なる便利な中継層になります。入口だけ整えても、下流側の権限が広ければ被害範囲は縮みません。

実務では、どの経路がどの下流 API を呼ぶのか、どの経路にどの権限が本当に必要か、どのサービスアカウントを共有しているのかを一覧化して確認する方が現実的です。BFF はアプリ開発の都合で増改築されやすいため、実装者の頭の中だけに依存すると、古い経路や不要な権限が温存されます。経路、権限、下流 API の対応表を持つこと自体が、BFF を安全に運用する前提になります。

運用で確認すべき証跡とレビュー

公開面台帳には、応答確認に必要な項目まで入れます

BFF を公開面として管理するなら、台帳へ載せる項目は URL だけでは足りません。ホスト名、パス、メソッド、管理責任者、認可方式、下流 API、使う資格情報、ゲートウェイ配下かどうか、オリジン直アクセスの有無、プレビュー用ホスト名の有無まで残しておくと、設計変更後にどこを見直すべきかを短時間で判断しやすくなります。BFF は画面追加や機能統合のたびに経路が増減するので、台帳が薄いと古い経路を置き去りにしやすくなります。

とくにリリース前後では、「経路を整理した」「ゲートウェイへ集約した」「トークンの権限を縮めた」という設計変更が、本当に公開面へ反映されたかを確認する必要があります。そのときに必要なのは、構成図よりも実応答です。古いホスト名がまだ名前解決するか、管理用 API が別応答を返していないか、古いパスがまだ残っていないかを見れば、設計上は消したつもりの入口を見つけやすくなります。

設計レビューと公開面レビューを分けると運用が安定します

BFF のレビューを一つにまとめると、開発側は認証実装や画面都合へ寄り、プラットフォーム側はゲートウェイや WAF 設定へ寄り、公開面の実態確認が後回しになりがちです。そこで、設計レビューではブラウザ境界、認可、下流トークンを見て、公開面レビューではホスト名、経路、直アクセス、プレビュー残置を確認する、と役割を分けた方が回しやすくなります。内部設計の正しさと、外から見える状態の正しさは別レビューにするのが実務向きです。

この分け方をしておくと、BFF の機能追加が続く環境でも、何を誰が確認すべきかが崩れにくくなります。設計レビューで合格しても、公開面レビューで古いホスト名やデバッグ用経路が見つかればリリースを止められますし、逆に公開面が整理されていても、下流 API の権限が広ければ設計側で差し戻せます。二重のレビューを持つことが、BFF を「便利だが危ないまま」にしない条件です。

確認結果はリリースごとの証跡として残します

BFF の公開面確認は、一度やれば終わりではありません。フロントエンドや認証周りの改修があるたびに、経路やホスト名は変わります。そのため、リリースごとに「何を消したか」「何を残したか」「どのホスト名を確認したか」「古い経路はどうなったか」を証跡として残すと、後から見直しやすくなります。証跡が残っていれば、古い経路が再び出てきたときにも、いつの変更で復活したかを追いやすくなるのが利点です。

BFF は設計上の説明がしやすい反面、運用証跡が薄いと安心感だけが先行します。だからこそ、台帳、設計レビュー、公開面レビュー、リリース証跡をセットで持つことが重要です。ここまでそろうと、BFF は単なる実装パターンではなく、公開 API 面として継続管理できる構成要素へ変わります。

BFF の公開面確認にASM診断 PROを活かすなら

BFF の設計見直しで難しいのは、開発チームの構成図では整理できていても、外から見るとどのホスト名や経路がまだ見えているのかが別問題になることです。ゲートウェイを通す設計、セッションを持つ設計、トークンをサーバー側へ寄せる設計ができていても、古いオリジン側ホスト名、プレビュー用ホスト名、管理用 APIが残っていれば公開面は消えていません。

ASM診断 PRO は、BFF の認証ロジックやトークン交換を置き換えるものではありません。一方で、設定変更後に外から見える API ホスト名や管理導線が残っていないかを洗い出す役割とは相性があります。内部では整理済みでも、外から見るとまだ見える経路を見つけることで、BFF の安全設計を公開面の実態とつなげやすくなります。

特に BFF はフロントエンドに近いぶん、プレビュー用経路や暫定経路が開発都合で増えやすいです。その状態で『BFF を入れたから安全』と考えると、設計の安心感と公開面の現実がずれます。内部の認証見直しと並行して、外から見えるホスト名 / 経路を別レーンで確認すると、構成図にない露出を拾いやすくなります。

もし今、BFF の経路整理、トークンの最小化、ゲートウェイ配下への集約を進めているなら、完了条件に「外からホスト名と経路を再確認した」を入れてください。ASM診断 PRO で外部公開資産を見直すと、BFF の内部設計改善を実際の公開面削減までつなげやすくなります。

よくある質問（FAQ）

BFF を使えばフロントエンドにトークンを置かないので十分安全ですか？

十分とは言えません。トークンをブラウザから隠せても、BFF 自体の公開経路、セッション Cookie、CSRF、直アクセス用ホスト名、管理経路の保護は別途必要です。BFF は安全性を高める手段ですが、確認対象を減らす魔法ではありません。

API ゲートウェイや WAF の後ろに置いていれば、BFF を公開面台帳に入れなくてよいですか？

入れるべきです。ゲートウェイ配下に正面入口があっても、オリジン側ホスト名、プレビュー用ホスト名、管理用 API が別経路で残ることがあるためです。BFF はアプリ内部の構成要素であっても、外から叩かれる経路を持つなら公開面台帳の対象です。

BFF の認可はフロントエンド側の画面制御で補えますか？

補えません。画面にボタンがなくても API へ直接リクエストできるため、経路ごと、オブジェクトごと、操作ごとの認可が必要です。フロントエンドの表示制御は UX であって、API の認可そのものではありません。

BFF で特に見落としやすい経路は何ですか？

プレビュー用ホスト名、デバッグ用経路、古い経路、管理用 API、下流 API への中継パスです。開発中の利便性のために作った経路が残りやすく、公開台帳から外れやすいためです。

BFF の外部公開面確認は開発チームだけで完結できますか？

難しいことが多いです。認証設計は開発チーム、公開ホスト名はインフラ、WAF / ゲートウェイはプラットフォーム、外からの見え方は別の観点になるためです。内部設計と公開面確認を分けて持つ方が実務では安定します。

まとめ

BFF は、ブラウザに長期トークンを持たせないための有力な設計パターンですが、その価値をそのまま「安全」と読み替えると危険です。BFF を入れるとトークンの境界は改善できますが、同時に BFF 自体が外から叩かれる公開 API 面になります。セッション Cookie、CSRF、CORS、リダイレクト、下流トークン、認可、オリジン側ホスト名、管理経路まで含めて初めて安全性を判断できます。

特に見落としやすいのは、フロントエンドの画面制御と API の認可を混同すること、ゲートウェイの正面入口だけ見てオリジン側ホスト名やプレビュー用ホスト名を見落とすこと、BFF が持つ下流トークンの権限を縮めずに済ませることです。BFF は便利な集約層ですが、外部公開面として台帳に載せなければ、古い経路やデバッグ用経路が残っても気付きにくくなります。

実務では、BFF を構成図の要素として扱うだけでなく、外部公開面台帳と API 台帳の両方へ載せ、経路、メソッド、管理責任者、認可、下流トークン、エッジ制御を並べて確認する方が安定します。内部の安全設計と外からの確認を分けて持つと、設計の安心感と公開面の実態がずれにくくなります。

最後は、BFF の導入有無ではなく、BFF のホスト名と経路が外からどう見えるかを確認してください。BFF は『入れれば安全』な部品ではなく、『入れたあとに何を確認すべきかが増える部品』です。この前提で棚卸しと再確認を回せるようになると、BFF の価値を生かしながら公開面の事故を減らしやすくなります。