Transloadit

What is CDN Security?

CDN security comprises controls that protect edge-delivered content and its origins. Common measures include TLS, signed requests, access rules, rate limits, and denial-of-service mitigation.

How CDN Security works

A CDN sits between viewers and the origin, so it has two sides to secure. Facing viewers, it terminates TLS, can absorb or rate-limit abusive traffic, and can require every request to prove authorization, usually with a signed URL or signed cookie that carries an expiry and is verified at the edge. Amazon CloudFront validates the signature and policy first and only then checks its edge cache or forwards the request; Google Cloud CDN rejects a request with a bad signature without sending it to the backend. Validating a signature that is present is not the same as demanding one: CloudFront requires signed requests only for files matched by a cache behavior that has a signer, and Cloud CDN does not block a request that carries no signature at all, so there the origin has to refuse it. Because the CDN performs the signature check itself, signing need not fragment the cache: Cloud CDN states that all valid signed requests for the same base URL share one cache entry and that signed and unsigned requests never share one. Separately, when a request carries an Authorization header, a shared cache must not reuse the response unless it opts in with public, s-maxage, or must-revalidate (RFC 9111). Facing the origin, the CDN is just another HTTP client: the origin accepts direct requests unless it is restricted to the CDN, and the connection between the two is encrypted only if that is configured. Signing controls who may fetch a response from the edge. It does not encrypt the media.

Key facts

  1. Does a signed URL identify the viewer? No. It is a bearer credential: Google’s Cloud CDN documentation says anyone who knows the URL can use it until it expires or the signing key is rotated, and for that reason recommends short expiry times and handing out signed URLs only over HTTPS. Amazon CloudFront can additionally restrict a custom policy to an IP address or range. A short lifetime has a cost, because expiry is checked on every request: CloudFront documents that a download already in progress completes, but one resumed after the expiry time fails, as does any later range request. With a lifetime shorter than the playback session, the next request after expiry is therefore refused unless the application has by then issued a new credential with a later expiry.
  2. Signed URLs or signed cookies for HLS and DASH? A playlist or manifest points to many segment URLs, and each request must be authorized, so a signature on the playlist URL does not by itself authorize the segment requests. CloudFront and Cloud CDN both recommend signed cookies when access spans multiple files and both name HLS video as the example; in Cloud CDN the cookie authorizes every URL under a prefix until its expiry, so manifests do not have to be rewritten for each viewer, and access can be refreshed in the background with short expiry times. Signing every segment URL per viewer is possible but, in Google’s words, burdensome. Signed URLs remain the choice for individual files and for clients that do not support cookies. On both CDNs a signed URL takes precedence when a request carries both.
  3. Why does a correctly generated signed URL return 403? One documented cause is that the request no longer matches what was signed. CloudFront returns 403 when a query string is added to a URL after signing, and Cloud CDN requires its signing parameters in a fixed order with no change of letter case. When the whole URL is signed, anything a player, proxy, or origin needs in the query string must be in the URL before the signature is computed. Prefix-scoped credentials differ: Cloud CDN’s URL-prefix signatures and signed cookies do not cover query parameters, so extra ones are accepted but are not protected against alteration. On CloudFront, the resource named in a signed cookie’s custom policy is the URL including its query string, and a wildcard in that resource can match an added query string. Key rotation is another documented cause: Cloud CDN stops accepting a URL once its signing key is deleted, and CloudFront’s procedure adds the new public key, switches signing to it, and removes the old key only after every URL or cookie signed with it has expired.
  4. Is checking signatures at the edge enough if the origin is publicly reachable? No. CloudFront’s documentation says restricting the origin is not required for signed URLs to work but recommends it, because otherwise someone can bypass CloudFront with the origin’s own URL; Cloud CDN says the same about storage buckets. For a bucket that means removing public read access and granting it to the CDN alone: through an origin access control on CloudFront, or to the Cloud CDN service account on Cloud Storage. Locking a bucket does not empty the cache: Cloud CDN answers an unsigned request from a cache entry that already exists, and an entry normally stays until it expires or is evicted, so invalidate whatever was cached while the bucket was public once the origin refuses unsigned requests. For other origins the methods differ in strength: Cloudflare rates a secret request header or an allowlist of CDN IP ranges as moderately secure, and mutual TLS (Authenticated Origin Pulls) or a tunnel as very secure. HTTPS for viewers does not cover the origin leg either. In Cloudflare’s Flexible mode, which applies to viewer HTTPS on the default port 443, Cloudflare connects to the origin over plain HTTP, and CloudFront has a separate per-origin protocol setting, so a shared-secret header is only protected when that leg is encrypted as well.

When CDN Security matters

Configure these controls when media must reach only authorized viewers or when abusive traffic has to be stopped before it reaches the origin. The failures point in opposite directions: a signature that has expired or no longer matches the request locks out legitimate viewers, while an origin that still answers direct requests, or a CDN path that serves requests carrying no signature, lets anyone skip the checks. Before release, request protected files with no signature both through the CDN and from the origin’s own hostname, including files the CDN cached while they were still public; every such request must be refused.

How Transloadit helps with CDN Security

Transloadit’s Smart CDN supports signed URLs. Your back end computes an HMAC-SHA256 signature with the Auth Secret over the Workspace name, Template name, file path, and sorted query parameters, and appends it as sig next to an exp expiry. Because the transformation parameters are part of the signed string, changing them afterwards invalidates the URL. The expiry also limits how long a newly generated result may stay cached, so a shorter exp tightens access at the cost of cache reuse.

exp is given in milliseconds since the Unix epoch; the documentation calls it optional but strongly recommends setting it. Signatures have to be generated on the server because they use the Auth Secret, and the Auth Key must be enabled for Smart CDN use. Transloadit describes Smart CDN as a transformation and delivery layer that does not replace your application’s authorization policy: deciding which viewer receives a signed URL stays in your code.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free