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?