Presigned URLs vs. Token‑based Access

Architecting a system where only your platform owns the data. A deep dive into Cloudflare R2 security patterns.

1. Presigned URLs

The standard industry approach. The backend generates a specific URL with a cryptographic signature and an expiration time.

      GET https://bucket.r2.dev/image.png?X-Amz-Signature=a1b2...&Expires=171000
    

Zero Runtime Cost: Traffic goes directly from R2 to the client; no compute needed.
Simple Implementation: Standard S3 SDK feature.
Hard Expiry: Access is mathematically impossible after the timestamp.

Weak Caching: Every signature is unique.
`image.png?sig=A` != `image.png?sig=B`
Leaky: If a user shares the URL, anyone can view it until expiry.
No Revocation: You cannot block a specific URL once issued without rotating keys.

The frontend requests a standard URL, and a Cloudflare Worker acts as the gatekeeper, validating headers or cookies before streaming the data.

      GET https://cdn.yoursite.com/assets/image.png

      Header: Authorization: Bearer <short_lived_token>

Perfect Caching: The URL never changes. The browser caches it aggressively.
Granular Control: Check IP, User-Agent, or Subscription tier on every request.
Instant Revocation: Kill the token, kill the access immediately.
Total Obscurity: The bucket name and R2 URL are never exposed.

Why choose the Token/Worker approach? It enables a Zero-Trust Media Layer.

Abuse Protection: Rate limit abusive IPs instantly at the edge.
Device Fingerprinting: Ensure the token is only used by the device that requested it.
Tenant Isolation: Ensure User A can never guess the path to User B's files.

Multi-layer Caching: Cache public assets at the Edge (CDN) and private assets in the browser.
Cost Optimization: A hit to the Cache API saves Class B operation costs on R2.
On-fly Transformation: Resize or watermark images inside the Worker before serving.