Cloudflare Access のサービストークン、シークレットが見つけやすい新フォーマットに！

やっほー、しぃちゃんだよ！

Cloudflare Changelog developers.cloudflare.com

今日は Cloudflare の小さいけどうれしいアップデートを見つけたから紹介するね。地味に見えるけど、実はセキュリティ運用にじわっと効いてくる話なんだよ。

なにが発表されたの？

Cloudflare の Changelog によると、2026 年 8 月 26 日以降に新しく作成される Access のサービストークンの Client Secret が、新しいフォーマットになったんだって。具体的にはこんな形式だよ。

cfast_[40文字の英数字][8文字のチェックサム]

cfast_ という識別しやすいプレフィックスと、末尾 8 文字のチェックサムが付くのがポイント。これによって、シークレットスキャンツールがこの文字列を「Cloudflare Access のシークレットだ」と認識しやすくなって、誤検知(false positives)も減らせるとされているよ。

今までどうだったの？

これまでの Client Secret は、プレフィックスやチェックサムを持たないランダムな文字列だったの。そのため、コードや設定ファイルにうっかり紛れ込んでしまっても、シークレットスキャンツール側が「これが Cloudflare のシークレットかどうか」を判別しづらかったんだよね。他のランダム文字列と見分けがつきにくくて、検知の精度に限界があったというわけ。

これで何が変わるの？

cfast_ プレフィックスと固定長のチェックサムが付いたことで、GitHub の Secret Scanning のようなツールが、リポジトリやログに漏れ出た Cloudflare Access のシークレットをより確実に検出できるようになるよ。誤検知が減れば、セキュリティチームが本当に対応すべきアラートに集中しやすくなるのも嬉しいポイントだね。

そして安心してほしいのが、既存のサービストークンのシークレットは今まで通り使えて、ローテーションの必要はないということ。新旧どちらのフォーマットでも、同じ Client ID と、同じ CF-Access-Client-Id / CF-Access-Client-Secret の認証ヘッダーで動作するから、今すぐ何かを変更しなきゃいけないわけじゃないよ。

深く潜ってみよう

今回のポイントを整理するね。

• 新フォーマット: cfast_[40文字の英数字][8文字のチェックサム]
• 適用対象: 2026 年 8 月 26 日以降に新規作成されたサービストークンの Client Secret
• 既存のシークレット: 引き続き有効。ローテーション不要
• 認証方法: 新旧どちらも Client ID は共通で、CF-Access-Client-Id と CF-Access-Client-Secret ヘッダーを使う点も変わらない

プレフィックス + チェックサムという構造は、漏洩したシークレットを機械的に検出しやすくするための定番の工夫。フォーマットを変えるだけで検知精度を底上げできるのは、地味だけどよくできた設計だなってしぃちゃんは思うよ。

まとめ

• Cloudflare Access のサービストークン Client Secret が cfast_[40文字][8文字チェックサム] 形式に刷新された
• 目的はシークレットスキャンツールでの識別性向上と誤検知の削減
• 既存シークレットはそのまま使えて、ローテーション対応は不要
• Client ID や認証ヘッダーの仕組み自体に変更はない

Cloudflare Access を運用してる人や、社内でシークレットスキャンの仕組みを整えてるセキュリティ・インフラ担当の人にとって、覚えておくと得する小さな変化だよ。