この記事で分かること
- Cloudflare Workersの静的アセット配信が、Basic認証のミドルウェアをどうすり抜けたか
- AI VTuber「ゼロ号室」の配信で、なぜ認証ダイアログが画面に出てしまったか
- どちらも「守っているつもり」の認証が実際には効いていなかった理由
この記事で分からないこと(正直に書く)
- 同種の構成を使う他社製品にも同じ穴があるか(自社の2件の記録であり一般化はできない)
- ダイアログが出ていた正確な継続時間(発生と気づいた事実は分かるが実測はしていない)
何を作っていたか
Cloudflare Workers上で運用するチャットボット系プロダクトでは、管理画面などの一部パスにBasic認証をかけ、公開してよいパスだけをミドルウェアで通す構成にしていた。もう一つ、AI VTuber「ゼロ号室」の24時間配信では、配信画面が読み込む静的アセットの経路にBasic認証をかけていた(出所: 自社の運用記録、確認日2026-09-06)。
どこに穴が空いたか
1つ目は、Cloudflare WorkersのAssetsバインディングを使った構成で、管理画面のパスがBasic認証を経由せずHTTP 200を返す不具合だった。認証コードは書かれていたが、実行前に静的アセットが応答を返していた。もう1つは配信中に、Chromeのネイティブなサインインダイアログが画面中央に表示され、画面全体が暗転したまま放送が続いた事故で、同日中に2回発生した(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
1つ目は、Cloudflare Workersの静的アセット配信が既定でミドルウェアより先に処理される仕様だったためだ。公式ドキュメントも、run_worker_firstは「アセットに一致するリクエストでもWorkerを先に呼ぶか」を制御し、明示しない限りアセットが優先されると説明している(出所: Cloudflare公式ドキュメント「Static Assets - Configuration and Bindings」、確認日2026-09-06、https://developers.cloudflare.com/workers/static-assets/binding/#run_worker_first)。
2つ目が見つかりにくかったのは、監視がページの「中身」しか見ていなかったためだ。配信ページ自体は読み込み完了で健全に見え、遠隔撮影ではブラウザ本体のネイティブなダイアログは写らない。モニター画面をそのまま撮影して初めて分かった(出所: 自社の運用記録、確認日2026-09-06)。原因は、認証情報を注入するスクリプトが注入直後に接続を閉じる作りで、以後アセットの参照先URLが変わるたびに認証情報が付かなくなり401でダイアログが出る流れだった。
どう直したか
1つ目は2026年6月、[assets]ブロックにrun_worker_first = trueを追加し、両パスへ実際にリクエストを送って応答コードを確認する手順も加えた。2つ目は2026年8月、注入直後に閉じるスクリプトをやめ、接続を常時張ったまま注入を維持し、切断されたら張り直す常駐処理に置き換えた(出所: 自社の運用記録、確認日2026-09-06)。
同じ穴を持つ製品の見分け方
- 静的アセット配信とミドルウェア認証を両方使う場合、認証必須パスへ実際にリクエストを送り応答コードを確認したか
- 常時起動のブラウザで認証情報を注入している場合、注入は一度きりか、途切れても保持され続ける作りか
- 画面監視が「中身」しか見ていない場合、ネイティブなダイアログを検知できない盲点を認識しているか
認証情報の更新で管理者権限を失った記事も、正しく動いているはずの手順の裏に穴があった事故を扱う。監査ログ設計の記事は「誰が何にアクセスしたか」を後から追跡できる設計を扱う。
自社のAI製品の認証設計・配信監視について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. Basic認証を設定していたのに、なぜ効いていなかったのか
静的アセット配信が既定でミドルウェアより先に処理される仕様だったため。認証コードはあったが、実行前にアセットが応答を返していた。
Q2. 配信画面に認証ダイアログが出た原因は何か
認証情報を注入するスクリプトが注入直後に接続を閉じる作りだったため。以後アセットの参照先が変わるたびに認証情報が付かず、401でダイアログが出た。
Q3. なぜ画面監視で気づけなかったのか
監視がページの「中身」を撮影する方式で、ブラウザ本体のダイアログはそれには写らないため。モニター画面をそのまま撮影して初めて分かった。
Q4. それぞれいつ直したのか
静的アセットの穴は2026年6月にrun_worker_firstの設定を追加して直した。配信の認証ダイアログは2026年8月に、認証情報の注入を維持し続ける常駐処理に置き換えて直した。