Sitecore Media Request Protection errors with CDN enabled

Question

We have CDN enabled on our website and we are seeing a lot of errors w.r.t Media request protection like the below:

ERROR MediaRequestProtection: An invalid/missing hash value was encountered. The expected hash value: 7364B46DCB96C3AC10AA02945E8D17D4. Media URL: /-/media/Feature/Blogs/image.jpg?rev=d4e6f5191f9549d5bc3f9efe96db7861, Referring URL: (empty)

As far as I understand about MRP, it is used to prevent an image resize vulnerability and Sitecore expects a generated hash value as a query string to a media URL.

When the media requests are going to CDN, even if someone tries to alter the image properties it still serves the same from CDN. My question is do we need to handle all the images to have hash value or is it just safe to disable the media request logging with the setting - Media.RequestProtection.Logging.Enabled = false.

This error also occurs for all of the media assets like the optimized files under SXA themes. How do we handle such cases?

Thanks!

Answer 1

I think that this is a bug in Sitecore.

Here's whats happening

• When you enable the CDN config, it sets Media.AlwaysAppendRevision to true
• This appends rev=xxx to all media urls
• The media request protection protectedMediaQueryParameters config has <parameter name="rev" description="media revision"/>.
• The media request protection code in Sitecore.Resources.Media.MediaRequest checks if any protectedMediaQueryParameters are in the request, and if so, it will check that there is a hash. If there's no hash it will log that message ERROR MediaRequestProtection: An invalid/missing hash value was encountered.

Notes

I think having rev in protectedMediaQueryParameters config is required as it is used for the Sitecore MediaCache. If you remove it then rev won't affect the cache which could cause some unintended consequences, but it is an option to fix this issue if you understand the effects on your solution.

I can see that in Sitecore 9.3 this code has changed a lot so attempting to fix this bug yourself via code changes will probably be a bit of a pain come upgrade time. That said, the bug still exists in 9.3.

I haven't opened a support ticket for this, but urge you to do so.

Answer 2

I stumbled across this while looking for a solution to the same issue and thanks to Mark's info I was able to get rid of the log spam by simply wrapping the GetMediaUrl in an extension method in which i'm forcibly appending something that will be hashed with the media protection logic (so there will always be a hash value appended for places that I need it). You can try something like this..

public static string GetMediaUrl(MediaItem mediaItem)
        {            
            string url = string.Empty;
            if (mediaItem != null)
            {
                url = MediaManager.GetMediaUrl(mediaItem);                
                
                // in order for ProtectAssetUrl to work we need to append image params which will then be hashed.. Using language which shouldn't be an issue if someone actually sets width/height for example: https://sitecore.stackexchange.com/a/24490/2539                
                url = url + "?la=en";
                url = HashingUtils.ProtectAssetUrl(url);
            }
            return url;
        }  

I'm using this for a specific scenario where we're pushing media urls into an custom index through a computed field but it means that there is a hash present and removed all the errors being logged. Language seemed like a non-problematic option to force in for my scenario.

Credit goes to Mark Gibbons and his original answer