Locking down requests from Sitecore to Head

For those coming from on-prem or PaaS the leap to the exciting new world of Sitecore SaaS can be quite daunting, with many new factors and considerations - not the least of which is security (which should always be front-of-mind).  Your dev teams may be busy brushing up on containers and headless, but infra teams will be more concerned with integrating with XM Cloud, most notably with the Head.

Most of you will (hopefully) already be familiar with a couple of the ways that communication between the Head and Sitecore can be secured:

1. A Sitecore API key - allows you to lock down your API calls to the Layout Service and GraphQL endpoints, as well as impersonate users.
2. The JSS Editing Secret - used as a shared key to ensure the app and Sitecore Editor are the only parties authorized to talk to one another while in Experience Editor mode.

But what if you want a bit of extra security? Say you have a WAF (something to that effect) which only allows certain headers? As always, Sitecore is nice and extensible:

The class making the HTTP call to your Head app is Sitecore.JavaScriptServices.ViewEngine.Http.RenderEngine and it creates a HttpClient to make the requests using Sitecore.JavaScriptServices.ViewEngine.Http.HttpClientFactory which has the following method:

public IHttpClient Create(HttpRenderEngineOptions options)
{
	Assert.IsNotNull(options, "options");
	return new TimeoutCapableWebClient(options.RequestTimeoutMs)
	{
		Encoding = Encoding.UTF8,
		Headers = { [HttpRequestHeader.ContentType] = "application/json" }
	};
}

This HttpClientFactory is created through DI, so you can just inject your own and add your own headers! Too easy!

"Invalid/missing hash was encountered" for documents

Reviewing our logs recently we discovered that we were getting an unusually large number of messages to the tune of
ERROR MediaRequestProtection: An invalid/missing hash value was encountered.

As we all know, Sitecore 7.5 added the concept of a hash which is required when resizing media items, so naturally we assumed that some images were being included incorrectly on a page somewhere, or the secret was incorrectly configured.  However, on closer inspection we realised that it wasn't actually images at all, but documents (which certainly aren't being resized, and surely don't need a hash).

Documents (mostly PDFs) were being uploaded to the media library, and then in a rich text field somewhere on the site, an author was linking to the document using insert link -> media item.

Upon reaching out to Sitecore, they were quick to reply that this was actually a bug in the current version of Sitecore (8.1 update 2 - 160302).  So if you're having a similar issue and want to clean out your logs a bit, you can contact support for the patch, and/or use the reference number 438674.