R2 バケットをキャッシュ用に公開（カスタムドメイン 経由）すると、URL を知る人は誰でもコンテンツにアクセスできます。アクセスを制限するには、Cloudflare の WAF で、キャッシュやバケットに届く前にリクエストを検証します。
次の図は、リクエストが WAF、Cache、R2 を通る流れです。WAF カスタムルールは リクエストパイプライン で Cache Rules より先に動くため、無効なリクエストはキャッシュのリソースを消費する前にブロックされます。
flowchart LR accTitle: Cloudflare との接続 A[ユーザーのリクエスト] --> B[WAF] --> C[Cache] --> D[R2]
署名付き URL（presigned URL）は、通常の URL に暗号トークンを付けたものです。トークンには、URL パス、タイムスタンプ、署名サービスと検証側で共有する秘密鍵から計算した HMAC（ハッシュベースのメッセージ認証コード）が含まれます。URL を持つ人は、トークンの有効期限までコンテンツにアクセスできます。ただし、別の URL パスにトークンを再利用することはできません。
S3 ↗ と同様に URL へ署名し、有効期限付きでコンテンツへ直接アクセスを共有できます。この方式は、Snippets、Rules、Cloudflare Workers の組み合わせで実装できます。
最適な性能を得るには、作成と検証を分けることを推奨します。
- HMAC の作成（URL への署名）は Snippets
- HMAC の検証（各リクエストでのトークン確認）は WAF カスタムルール
Workers のドキュメントでは、Signing requests の例で、HMAC による署名付きリクエストの生成と検証の両方を示しています。Workers の実装は、WAF の is_timed_hmac_valid_v0() 検証関数 と互換です。Workers で署名して WAF カスタムルールで検証することも、両方を Workers で扱うこともできます。