Transloadit

What is a Signed URL?

A signed URL contains cryptographic proof that an authorized party granted access to a resource or transformation. Its signature commonly covers an expiration time and request-specific path or query parameters.

How Signed URLs work

A signer that holds a key builds a string from the parts of the request it wants to authorize, typically the path, selected query parameters, and an expiry, computes a signature over that string, and appends the signature to the URL. The service verifies the signature and checks the expiry before it serves anything. Two key models are common. With an HMAC, the signer and the service hold the same secret; Google Cloud CDN and Transloadit’s Smart CDN work this way. With a key pair, the signer keeps a private key and the service needs only the public key; Amazon CloudFront verifies RSA or ECDSA signatures against public keys in a trusted key group. Either way this is delegated authorization, not encryption. AWS describes presigned URLs as bearer tokens, and Google states that anyone in possession of a signed URL can use it while it is active. A presigned URL is the object-storage case: Amazon S3 uses that name for a URL that carries its creator’s credentials for one bucket, one object key, and one HTTP method, such as a GET download or a PUT upload, while Google Cloud Storage calls its equivalent a signed URL.

Key facts

  1. Can a query parameter be added or changed after signing? Only if the scheme leaves it outside the signature or the signed policy allows it. CloudFront returns HTTP 403 when a query string is added to a signed URL after signing. A CloudFront custom policy can widen this: its Resource URL may contain wildcards, CloudFront matches the requested URL against that pattern, and a trailing asterisk in the path also matches the query string. imgix returns 403 when the path or parameters change after its s parameter is set. Schemes that sign a canonical request are also sensitive to how the request is made: S3 and Google Cloud Storage V4 signatures cover the HTTP method, the path, the sorted query string, and the host header, so a URL signed for one method or hostname does not validate for another. Google Cloud CDN is a deliberate exception when you sign a URLPrefix instead of the full URL: query parameters are then not signed and can be freely included, and one signature is valid for every URL that starts with the prefix.
  2. Why would a presigned URL stop working before the expiry that was set? Usually because the credentials behind it expired first. AWS states that an S3 presigned URL expires at its configured time or when the credentials that created it expire, whichever occurs first, so a URL signed with temporary role credentials ends with the role session even if a longer lifetime was requested. Google Cloud Storage signed URLs likewise stop working when the key used to sign them is rotated. AWS also lists clock drift on the signing machine and proxies that modify headers or query strings as causes of signature mismatches. Sign with credentials that outlive the URL, or issue URLs shorter than the session.
  3. What happens to a download or playback that is still running at expiry? The expiry is checked when each HTTP request arrives, not while a response is being sent. S3 and CloudFront both document that a download started just before the expiry continues, and that a client that reconnects after the expiry fails. On CloudFront, any Range GET issued after the expiry also fails. A player that fetches a large file in ranges, or a download manager that resumes, therefore needs a lifetime that covers the whole session or a way to obtain a fresh URL.
  4. Does requiring signed URLs at the CDN protect the origin, and are signed responses still cached? The CDN checks the signature; the origin is a separate entry point. AWS recommends, but does not require, restricting an S3 bucket so that it can be read only through CloudFront. Google warns that Cloud CDN does not block requests that carry no signature, so a Cloud Storage origin behind it must not be public. On caching, CloudFront and Google Cloud CDN remove the signature parameters before forwarding a request to the origin, and Google validates the signature first and then serves from cache, storing responses to signed and unsigned requests separately. That separation does not clear what was cached while the content was public: Cloud CDN serves an unsigned request from cache on a cache hit, so after closing the origin, invalidate the previously cached responses or wait for them to expire. Some services tie cache lifetime to the expiry: imgix replaces Cache-Control with the time left until expires.

When Signed URLs matter

Use signed URLs to give a browser, player, or partner time-limited access to private media without handing out storage credentials or making the origin public. A signed URL authorizes whoever holds it, not a particular user, so choose a lifetime you would accept for a forwarded link, and add another check where access must stay bound to one person.

How Transloadit helps with Signed URLs

Transloadit’s Smart CDN accepts signed URLs. Your back end adds an exp timestamp in milliseconds and an auth_key, sorts the query parameters, computes an HMAC-SHA256 with the Auth Secret over the Workspace, Template name, file path, and sorted parameters, and appends the result as sig. Because the transformation parameters are part of the signed string, a signed URL cannot be edited to request a different variant. The expiry also bounds how long a signed response may be cached, so a shorter exp tightens access and lowers cache reuse. For files exported to your own bucket, the /s3/store Robot can return signed URLs through its sign_urls_for parameter.

The Auth Key used for signing must be enabled for Smart CDN use, and the signing has to run on your back end because it needs the Auth Secret. The documentation marks exp as optional and recommends always setting it. The linked pages describe how to sign a URL but not how an unsigned request to the same Template is treated, nor whether a range request that arrives after exp is refused, so test both on your own Workspace before treating signing as access control or choosing a lifetime shorter than a playback session.

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