Hi Team,
I am trying to generate signed URLs to access manifest/HLS files in one of our private buckets. I am following this documentation: Generating Signed URLs to generate signed path URLs, allowing the media player to fetch all HLS files within the path.
I have successfully generated signed path components using the following pattern, and the links work as expected in the media player:
https://domain.com/{pathToFile}/edge-cache-token=Expires={expiryTime}&KeyName=myKey&Signature={generatedSignature}/playlist.m3u8
However, I would like to enhance security by restricting access to requests that include specific custom headers with predefined values.
According to the documentation, we can pass HeaderName and HeaderValue while generating the signature (Optional Signature Fields), and these values will be validated at the Media CDN level.
To implement this, I added HeaderName={myHeader} and HeaderValue={myHeaderValue} while generating the signature as follows:
urlPatternToSign := fmt.Sprintf("%sedge-cache-token=Expires=%d&KeyName=%s&HeaderName=%s&HeaderValue=%s", prefixUrl, expirationTimestamp, keyName, "myheader", "myheadervalue")
This approach correctly verifies the headers from the request and produces the expected output. However, it also requires including HeaderName and HeaderValue in the URL itself, which exposes these values—defeating the purpose of using opaque identifiers in the request.
Example:
urlPatternToSign := fmt.Sprintf("%sedge-cache-token=Expires=%d&KeyName=%s&HeaderName=%s&HeaderValue=%s", prefixUrl, expirationTimestamp, "my-key", "myheader", "myheadervalue")
Could you clarify if my understanding is incorrect or if I am missing something in the implementation? Ideally, I want the request to be validated using headers without exposing them in the URL itself.
Any help from the team would be really appreciated.
Hi @jainnaman16,
Thank you for your question regarding *Google Cloud Media CDN signature
with headers*. You're correct in aiming to restrict access via custom
headers for enhanced security. However, including HeaderName and HeaderValue
in the URL contradicts the purpose of using them as an additional security
measure.
Here’s how you can approach this correctly:
*Recommended Approach*
1.
*Use Signed Policy Documents*
Instead of adding the headers directly to the URL, use *signed policy
documents* to enforce header validation at the Media CDN level. This
ensures that only requests containing the specified headers will be allowed
access.
2.
*Leverage Google Cloud IAM & Signed Cookies*
- You can use *signed cookies* instead of signed URLs, which helps keep
the security parameters separate from the URL itself.
- Signed cookies enable you to control access without exposing tokens
in the URL, and they work well with Media CDN.
3.
*Validate Headers at the CDN Level*
- Ensure that your CDN’s *request validation policy* enforces the
required headers.
- This can be configured using Cloud Armor or a backend validation
mechanism.
4.
*Avoid Exposing Sensitive Information in the URL*
- If HeaderName and HeaderValue are included in the URL, anyone with
access to the URL can reconstruct a valid request.
- Instead, configure your CDN and/or backend to *only process
requests containing specific headers*.
*Next Steps*
- Can you confirm whether your Media CDN setup allows enforcing header
validation through Cloud Armor or a similar policy?
- Have you explored using *signed cookies* instead of signed URLs for
additional security?
Let us know if you need further clarification. Happy to help!
Best,
Google Cloud Media CDN Team
-
Project Director
Nature Labs
Google Engine
<URL Removed By Staff>
Thank you for the prompt response!
We have not yet explored the signed cookies or Cloud Armor approach.
Our initial assumption was that the signed URL method would allow us to generate unique, user-specific URLs, enhancing security and preventing unauthorized access to our data.
We will look into the signed cookies approach, though it would require some client-side modifications.
Regarding Cloud Armor policies, my understanding is that it helps in enforcing security by allowing specific headers (with predefined values) and/or IP addresses. This would certainly add an extra layer of protection, however, it does not seem to solve our initial problem for user/device-specific validation using unique identifiers. Could you confirm if my understanding is correct?
Thanks,
Naman
We have switched to the dual token authentication approach instead of signature URLs since it allows for headers validation without exposing the values in the URL.
Documentation: https://cloud.google.com/media-cdn/docs/use-dual-token-authentication
Thanks,
Naman