Chrome – OTS parsing error: invalid version tag

I saw this weird warning in Chrome’s DevTools while looking at a site:

OTS parsing error: invalid version tag

Uh-huh. That’s a bit strange. Unable to download fonts? What caused that?

Well, I tried going to the font’s URL – and got the ‘Page Not Found’ page! Well, that’s annoying – but a 404 page is clearly not a font.

However, this site’s error pages return HTTP 200 – so Chrome expects a font…

Make sure your error pages return a correct HTTP status code. If you don’t, it can cause problems. Normally, I find that it’s false positives on automated penetration tests, but this is a new and exciting variation.

Chrome – OTS parsing error: invalid version tag

Secure your Sitecore Cookies

So a Sitecore site I’ve been working on recently underwent a penetration test, which turned up an interesting item. The ASP.NET_SessionId and SC_ANALYTICS_GLOBAL_COOKIE cookies aren’t set with the ‘Secure’ flag.  Further, my own checking showed that the .ASPXAUTH token was also set without the ‘Secure’ flag.

As the entire site is only served over HTTPS, this seems to be a bit remiss.

Fortunately, there are a couple of easy fixes to this that can be set in the Web.config

Under <System.Web> and <httpCookies> set requireSSL:

<httpCookies requireSSL="true" />

And in <forms> set requireSSL too.

<forms name=".ASPXAUTH" cookieless="UseCookies" requireSSL="true" />

This latter one is needed for the .ASPXAUTH cookie, but that seems to do it.

Don’t forget to set the HTTPOnly flag as appropriate for your cookies too!

Secure your Sitecore Cookies

IIS Redirect HTTP to HTTPS

Just a quick note – if you want to use an IIS rule to redirect users from HTTP to HTTPS, the following rule seems to work pretty well. You’ll need the IIS URL Rewrite module installed.

<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<add input="{HTTPS}" pattern="^OFF$" />
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther" />


IIS Redirect HTTP to HTTPS

Configuring a Content-Security-Policy

I’ve talked about how to how to remove HTTP Headers that you don’t need from IIS – but there are some that you probably will want. This particular post is about the Content Security Policy (CSP).

I’m not going to describe what one is. @Scott_Helme has already described what a Content Security Policy is far better than I can. Rather, I’m going to describe how to figure out what your policy should be… Continue reading “Configuring a Content-Security-Policy”

Configuring a Content-Security-Policy

Removing Chatty IIS Headers

IIS is, by default, a bit too damn chatty, which isn’t what you want if you’re trying to harden your server:


You can check this with a site like, which will review all your HTTP Headers for you. It’s very good, I recommend it.

Why would I need to tell the world what ASP version, webserver, etc. that I’m using? Isn’t this just helping potential attackers? Well, yes. How do you remove these headers, though? Continue reading “Removing Chatty IIS Headers”

Removing Chatty IIS Headers

You’re checking your HTTP Headers, right?

In the rush to build a website, it’s pretty easy to overlook something as mundane as HTTP headers – until someone runs an automated pen-test against the site you’ve built and starts asking about why you’re not using them – or why you are. Then you have to run around quickly trying to fix this – and some of these tasks aren’t so easy.

All of this can be fixed with a little testing beforehand, and there is a nifty site called


This will tell you:

What headers you’re using and probably shouldn’t. IIS seems determined to include lots of HTTP Headers that you don’t need. This just leaks information to someone who is potentially malicious, and wastes a little bandwidth.

What headers you should use. There are a number of slightly obscure security related headers, and some new (and good) ones, such as a Content Security Policy, or HTTP Public Key Pinning.

Also, for what it’s worth, is by a chap called Scott Helme – (@Scott_Helme). He’s written about a lot of this stuff quite extensively, and also has written, which as we’ll see is fantastically useful.

Other ways of seeing your HTTP Headers…

  • Fiddler (Of course)
  • Browser Developer tools – such as Chrome’s – can show the response headers
  • Chrome’s HTTP Headers plugin – there are other plugins (and plugins for other browsers), but I find it very good for just doing what it says.



You’re checking your HTTP Headers, right?

Handling 404s in Sitecore

Sitecore lets you specify a page to use for ‘ItemNotFound’ errors in web.config, and it’s always good practice to have a pretty ‘page not found’ page:

<setting name="ItemNotFoundUrl" value="/404" />

However, Sitecore hasn’t always been the best for actually returning the right HTTP status code for the 404 page. It redirects (more on that later) your failed request to a specified page in Sitecore – but the serves that page correctly, including an HTTP 200 status. This is sad, as search engines don’t understand that the page actually hasn’t been found. Continue reading “Handling 404s in Sitecore”

Handling 404s in Sitecore

The X-SharePointHealthScore header

A reminder to myself – there is a response header for SharePoint requests called the X-SharePointHealthScore. It indicates how stressed the server is with a score from zero (unstressed) to 10 (highly stressed). I first stumbled across it when debugging something in Fiddler, but others have written about it:

  • Andrew Connell has a brief write up
  • Mick Breeze dug into it with Reflector
  • Michel Barneveld seems to have found it the same way as I did – but looks at how it is calculated. He also describes how to force SharePoint to return a given value, in case you need to test something (like how your client code handles a stressed server)

So how do we test the loadbalancer if we set it up in this fashion? Do we need to DDoS a WFE? There is a better way 😉 There is a registry setting that will override the Health Score and it will return the value from the registry.

Create a DWORD with the name ServerHealthScore in the following location: HKLMSOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0WSS and give it the value you want.

So what’s it useful for? Well, the main things that strike me would be:

  • Server Monitoring – Pretty obvious, really.
  • Client Applications – Can warn or take corrective actions if the server is loaded and may implement throttling.
  • Client Side scripts – Similar to above, though I haven’t yet been able to figure out who you’d get this value in the Client Object Model. I’m assuming there is a way to get the response headers in the Client Object Model – otherwise you may have to use normal XMLHttpRequests if you want to see the response headers.
The X-SharePointHealthScore header