Private content and signed URLs

Overview

Cloud CDN signed URLs enable you to serve responses from Google Cloud Platform's globally distributed caches, even when you need requests to be authorized.

Signed URLs give a client temporary access to a private resource without requiring additional authorization. To achieve this, selected elements of a request are hashed and cryptographically signed using a strongly random key that you generate. When a request uses the signed URL that you provided, the request is considered authorized to receive the requested content. When Cloud CDN receives a request with a bad signature for an enabled service, the request is rejected and never goes to your backend for handling.

Generally, a signed URL can be used by anyone who has it. However, a signed URL is usually only intended to be used by the client to which the URL was given. To mitigate the risk of the URL being used by a different client, signed URLs expire at a time chosen by you. To minimize the risk of a signed URL being shared, set it to expire as soon as possible.

How URLs are signed

Before you can sign URLs, you create one or more cryptographic keys on a backend service, backend bucket, or both. Then you sign and cryptographically hash a URL using the gcloud command line tool or your own code.

Distributing signed URLs

When signed URL handling is enabled on a backend, Cloud CDN gives special handling to requests with signed URLs. Specifically, requests with a Signature query parameter are considered signed. When such a request is received, Cloud CDN verifies the following:

  1. The HTTP method is GET or HEAD.
  2. The Expires parameter is set to a future time.
  3. The request's signature matches the signature computed using the named key.

If any of these checks fails, a 403 Forbidden response is served. Otherwise, the request is either proxied to the backend or served from the cache. All valid signed requests for a particular base url (the part before the KeyName parameter) will share the same cache entry. Responses to signed and unsigned requests do not share cache entries. Responses are cached and served until the expiration time you set.

Content that requires signed requests is often marked as uncacheable using the Cache-Control header. To make such objects compatible with Cloud CDN without requiring backend changes, Cloud CDN overrides the Cache-Control header when responding to requests that have valid signed URLs. Cloud CDN treats the content as cacheable, and uses the max-age parameter set in your Cloud CDN configuration. The response served still has the Cache-Control headers that the backend generated.

The URL returned from the gcloud command line tool or produced by your custom code can be distributed according to your needs. We recommend signing only HTTPS URLs, because HTTPS provides a secure transport that will prevent the Signature component of the signed URL from being intercepted. Similarly, you should distribute the signed URLs over secure transport protocols such as TLS/HTTPS.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud CDN Documentation