作者は自分の静的サイトが誰でもリクエストすれば内部のエンジニア引き継ぎドキュメントを提供していることに気付きました。この150KBのファイルには、オンボーディング中の支払いをバイパスする管理者クエリーストリングパラメータ、アカウントを支払いなしで有料マークできる既知のスキーマホールの説明、データベース識別子、.claude/launch.jsonやGitHubワークフローファイルなどのツール設定が含まれており、本番ドメインで公開されていました。これは静的ホストのビルド出力ディレクトリがリポジトリのルートに設定されていたため、コミットされたすべてのファイル（ドットディレクトリやドキュメントを含む）が公開URLとして公開されたことが原因です。
ファイルを削除して再デプロイし、さらに2回のキャッシュパージを行っても露出を解消することはできませんでした。レスポンスヘッダーを調べたところ、`cf-cache-status: DYNAMIC`かつ経過時間が徐々に増加（4,396秒から67,735秒）していることが判明し、ゾーンレベルのキャッシュがファイルを保持していないことを示していました。代わりに、静的ホスト自身のアセット/エッジ層が古いコピーを提供していました。これは、プロバイダーのデフォルトドメイン（pages.dev）がきれいなバージョンを提供しているのに対し、カスタムドメインが古いファイルを引き続き提供していたことから確認でき、パージツールと古いコピーを保持している層が異なるシステムであることが証明されました。
最終的に、リークしたドキュメントのパス、.claude/、.github/ などの特定のパストークンに一致するリクエストをブロックするエッジのファイアウォールルールを追加することで漏洩は塞がれました。このルールはキャッシュ参照より前に実行され、即座に効果を発揮します。ドキュメントで明らかになった管理者パラメータをローテーションしてもほとんど保護になりませんでした。なぜならその値はクライアント側のソースに埋め込まれており、ローテーション後も見え続けていたからです。作者は、リークされたドキュメントに記載されているサーバーサイドのスキーマホールを塞ぐことが本当の解決策だと強調しています。これにより、誰がそのパラメータを知っていようと管理者パラメータは無効になります。