Clickjacking, XSS and CSRF, exploits that have been around for 15+ years now and still form the basis for many vulnerabilities on the web today. If you spend any time around bug bounty programs you will notice similar patterns with these exploits, that many could have been prevented with just a few HTTP Headers in place. A website that goes into production without these is asking for an exploit. Even if they have “other mitigations” in place, on most platforms it takes all of 5 minutes to add in a custom header which could save your site from an unfortunate vulnerability.

These headers should be on any “go live” checklist unless there is a specific reason why they can’t be (For example it’s an internal site that is going to be framed elsewhere, you may not want to disallow frames). While this site focuses on .net core, these headers are language and web server agnostic and can be used on any site.


X-Frame-Options tells the browser that if your site is placed inside a HTML frame, to not render anything. This is super important when trying to protect yourself against click jacking attempts.

In the early days of the web, Javascript frame breakers were all the rage to stop people from framing your site. Ever seen this sort of code?

It was almost a staple in the early 2000’s. But like most things Javascript, people found ways to get around it and invented a frame breaker breaker. Other issues included human error aka ensuring that the frame breaker code was actually on every page of your site. That one page you forgot to include the javascript snippet on? Yeah that’s the exact page someone used for clickjacking. Happens all the time!

A http header that disallows frames server wide with full browser support should be your go to even if you want to use a javascript framebreaker side by side.

X-Frame-Options is most commonly set to be “SameOrigin”, that is that the website can frame itself. But unless you actually have a need for this, the option of “Deny” is your best bet.

A guide to using X-Frame-Options in .net core can be found here.


X-XSS-Protection is a header that activates a browsers own XSS protection. All modern browsers have inbuilt XSS filtering capabilities that try and catch XSS vulnerabilities before the page is fully rendered to you. By default these are turned on in the browser, but a user may go ahead and switch them off. By using the X-XSS-Protection header, you can actually tell the browser to ignore what the user has done and enforce the inbuilt filter.

By using the “1;mode=block” setting, you can actually go further and stop the entire document from rendering if a XSS attack is found anywhere. (By default it removes only the portion of the document that it detects as XSS).

Infact, “1;mode=block” should be the only setting you use for X-XSS-Protection. Using only “1” could actually be a vulnerability in of itself. For more read here :

Another thing to note is that the browsers XSS filters are routinely bypassed by new ways of sneaking things through. It’s never going to be 100%. But it’s always a base level of protection that you would be silly to not utilize.

A guide to using X-XSS-Protection in .net core can be found here.


X-Content-Type-Options is a header I often see missed because in of itself, it’s not an exploit per-say, but it’s usually paired up with another vulnerability to create something much more damaging. A good example is the Json Array Vulnerability (Now fixed) that was around for a very long time. It allowed browsers to run a JSON array as javascript, something that would not be allowed had X-Content-Type-Options been set.

The header stops a browser “guessing” or ignoring what the mime type of a file is and acting on it accordingly. For example if you reference a resource in a <script> tag, that resource has to have a mime-type of javascript. If instead it returns text/plain, your browser will not bother running it as a script. Without the header, your browser really doesn’t care and will attempt to run it anyway.

A guide to using X-Content-Type-Options in .net core can be found here.

Content Security Policy

While you are reviewing security, why not take a look at implementing a Content Security Policy (CSP). While it doesn’t have as large of browser support as the previous headers mentioned, it is the future of securing browsers and wouldn’t hurt to add. After all, when it comes to security you want to close all the doors, not just the ones you think people will actually walk through.

X-Content-Type-Options is a header that tells a browser to not try and “guess” what a mimetype of a resource might be, and to just take what mimetype the server has returned as fact.

At first this header seems kinda pointless, but it’s one of the simplest ways to block attack vectors that use javascript. For example, for a long time browsers were susceptible to a very popular JSON Array Vulnerability. The vulnerability essentially allowed an attacker to make your browser request a non-javascript file from a site, but run it as javascript, and in the process leak sensitive information.

For a long time, anything within a script tag like so :

Would be run as javascript, irrespective of whether the return content-type was javascript or not. With X-Content-Type-Options turned on, this is not the case and if the file that was requested to be run does not have the javascript mime-type, it is not run and you will see a message similar to below.

Refused to execute script from ‘’ because its MIME type (‘application/json’) is not executable, and strict MIME type checking is enabled.

On it’s own the header might not block much, but when you are securing a site you close every door possible.

Another popular reason for using this header is that it stops “hotlinking” of resources. Github recently implemented this header so that people wouldn’t reference scripts hosted in repositories.

X-Content-Type-Options Settings

X-Content-Type-Options : nosniff
This is the only setting available for this header. It’s an on/off type header with no other “settings” available.

Setting X-Content-Type-Options At The Code Level

Like other headers, the easiest way is to use a custom middleware like so :

Setting X-Content-Type-Options At The Server Level

When running .net core in production, it is very unlikely that you will be using Kestrel without a web server infront of it (Infact you 100% should not be), so some prefer to set headers at the server level. If this is you then see below.

Setting X-Content-Type-Options in IIS

You can do this in Web.config but IIS Manager is just as easy.

  1. Open IIS Manager and on the left hand tree, left click the site you would like to manage.
  2. Double click the “HTTP Response Headers” icon.
  3. Right click the header list and select “Add”
  4. For the “name” write “X-Content-Type-Options” and for the value “nosniff”

Setting X-Content-Type-Options in Apache

In your httpd.conf file you need to append the following line :

Setting X-Content-Type-Options in htaccess

Setting X-Content-Type-Options in NGINX

In nginix.conf add the following line. Restart NGINIX after.

API Versioning is either something you love or you hate. It’s great for giving developers the ability to improve and iterate on API’s without breaking contracts. At times the stagnation of innovation on an API is simply because of legacy decisions that cannot be reversed, especially on public API’s. But versioning can quickly get out of control, especially with custom implementations.

Microsoft has attempted to alleviate some of the pain with it’s own versioning package which can be used in core (And other .net platforms). It can be a bit tricky to get going and it takes a few “aha” moments to get everything sitting right. So let’s see how it works.


First, you will need to install the following nuget package from your package manager console.

In the ConfigureServices method of your startup.cs, you need to add the API Versioning services like so :

The ReportAPIVersions flag is optional, but it can be useful. It allows for the API to return versions in a response header. When calling an API with this flag on, you will see something like the following.

The flag for “AssumeDefaultVersionWhenUnspecified” (Quite the mouthful), can also be handy especially when migrating an API to versioning. Without it, you will break any existing clients that aren’t specifying an API version at all. If you are getting the error “An API version is required, but was not specified.”, this will be why.

The DefaultApiVersion flag is also not needed in this case because it defaults to 1.0. But I thought it helpful to include it as a reminder that you can “auto update” any clients that aren’t specifying a default API version to the latest. There is pros and cons to doing this, but the option is there if you want it.

URL Query Based Versioning

Take a look at the following basic controllers. They have been decorated with an ApiVersion attribute, and their classes have been updated so they don’t clash with each other.

You’ll notice that the routes are actually the same, so how does core determine which class to use?

Actually the default way that the versioning library uses is by using a query string of “api-version” to specify a version.

So when I call /api/home?api-version=2.0, I am returned “Version 2”. When I call /api/home?api-version=1.0 (Or no version at all), I am returned “Version 1”.

URL Path Based Versioning

Query string parameters are nice and easy but don’t always look the best (And they can be a pain for an external client to always tag on). In a big long query they can be missed in the sea of query parameters. A common alternative is to put the version in the URL path so it’s always visible at the start of the URL.

Take the following two controllers :

Now when I call /api/1.0/home, I am returned Version 1. And /api/2.0/home will return me version 2.

Http Header Based Versioning

Specifying a version via an Http Header is a very common way of using Api Versioning. It allows your urls to stay clean without cluttering them with version information.

The defaults in the aspnet versioning package don’t actually support header information. You need to do a bit more work.

In your ConfigureServices method in startup.cs, you need to add the option of an ApiVersionReader to your AddApiVersioning call. Like so :

With this call I have told my API that the header “x-api-version” is now how I define an API version.

One word of warning. The above makes it so that you cannot use query string versioning anymore. So once you set the version reader to use the header, you can no longer specify the version like so /api/home?api-version=2.0

If you wish to use both, you need to use the aptly named “QueryStringOrHeaderApiVersionReader” which frankly is a ridiculous name but I guess it does what it says on the tin.

Version A Single Action

There may come a time when you want to only create a new version of an action, but not the entire controller (Infact there will be plenty of times). There is a way to do this, but a word of warning is that it will mean at some point in the future, you will have a mismatch of controllers, actions and versions etc. It can be hard to manage.

But to version a single action, you can do something that looks like the following :

Essentially we still need to tell the Controller that it supports 2.0, but within the controller we can use the “MapToApiVersion” attribute to tell it to be used with a specific version.

Deprecating A Version

You are able to deprecate an Api version. Note that this does not “delete” the version, it only marks it as deprecated so a consumer can know. When someone calls your API, they will see the following header returned.

But the point is, they can still call that endpoint/version. It does not limit it in any way.

Conventions Based Setup

Up to now we have defined the API Versioning with an attribute. This is fine but it can get out of hand when you have many controllers with different versions with no way to have an “overview” of the versions you have in play. It’s also a little limiting in terms of configuration.

Enter “Conventions” setup. It’s an easy way to define your versioning when adding the APIVersioning services. Take a look at the following configuration :

Pretty self explanatory and now we don’t have to put attributes on our controllers anymore and the configuration is all stored in the same location.

Accessing HTTP Version

There may come a time when you actually want to know what API Version was requested. While I would recommend not going down the route of large switch statements to find services (Or passing them into factories etc), there may be an occasion when you have a legitimate use for it.

Luckily, HttpContext has a method called “GetRequestedApiVersion” that will return you all the version info.

Opting Out Of Versioning

A scenario that is becoming more and more common is having a single project that works as an API and an MVC app all in one. When you add versioning to your API, your MVC app suddenly becomes versioned also. But there is a way to “opt out” if you will.

Take the following example :

Now actually, if you pass in a version of 2.0, this action will actually return 2.0. It still knows the version and can read it, it simply doesn’t care. Thus if you “force” a version number or minimum version, this controller is unaffected.

Anything I missed?

Have I missed something? Feel free to comment below.

HttpOnly is a flag that can be used when setting a cookie to block access to the cookie from client side scripts. Javascript for example cannot read a cookie that has HttpOnly set. This helps mitigate a large part of XSS attacks as many of these attempt to read cookies and send them back to the attacker, possibly leaking sensitive information or worst case scenario, allowing the attacker to impersonate the user with login cookies.

If you are interested in reading more on the background of HttpOnly cookies, OWASP has a great article here explaining them in more detail :

Now, onto how these can used in .net core.

Defaults Are Gone

An important thing to note in .net core compared to the .net framework, is that while previously you were able to set global defaults, you can no longer do this. For example in .net framework you were able to add the following to your web.config :

This would make sure that any cookies set by your application were HttpOnly. Obviously web.config is more or less out the window with .net core (Although if you are hosting on IIS you can still use it), and Microsoft hasn’t added in a global default able to be set yet. This may change in the future however because it was definitely a handy setting.

Setting A Cookie Manually

When setting a cookie manually (e.g. against an HTTPContext), there is an easy CookieOptions object that you can use to set HttpOnly to true. It ends up looking a bit like this :

When Using Cookie Authentication

Microsoft have a middleware that uses cookies for Authentication. If you were to use it in your app, you add it in the Configure method of your startup.cs.

If you are using CookieAuthentication in this way, HttpOnly cookies will be used by default. (You can check the source code here on Github). If you actually need this functionality off (Dangerous, but it’s a possibility), then you can override the functionality like so :

When Using XYZ Middleware

Because there is no global option for HttpOnly cookies, when using a third party middleware you are at their mercy as to how they set their cookies and whether they are HttpOnly or not. In some cases they may not be HttpOnly when you want them to be, and even vice versa when you actually need the cookie to be accessible. If you are building your own middleware that you intend to share as a library, the best option is leaving the default as HttpOnly set to true, and allowing the user to override it if they really feel the need.

It’s hard to read an intro to .net core without someone also introducing .net standard and then quickly moving on, leaving you to wonder just what is the .net standard. I’ve seen the same questions come up over and over again.  Is it another framework I have to learn? Is it the old .net? Is .net standard and .net core the same? Hopefully we can answer all those questions today!

.net Standard Is Exactly That. A standard.

.net standard is for lack of a better word, a standard. It’s a description of the core interfaces that every .net platform should implement if they wish to say “I support .net Standard 2.0” for example.

An easy way to see what exactly the standard defines is actually the nuget package here : . If you scroll down you will see descriptions of what each standard defines. So for example, .net Standard 1.1 introduces System.Linq. If you would like to use System.Linq, you will need to use a platform that implements .net Standard 1.1.

That brings us to the next point….

What Is A Platform?

It’s may be also good to take a step back and look at what exactly is a platform. At the moment the Microsoft .net platform list looks like .net Framework (Old .net), .net Core, Xamarin, Universal Windows Platform (UWP), Windows Phone and now also Mono.

Each platform version will implement a specific .net standard version. So for example, .net Framework Version 4.6 implements the .net Standard 1.3, whereas .net Core Version 1.0 implements .net Standard 1.6. If I were to write a library that I wanted a developer to use in both .net Framework Version 4.6 and .net Core Version 1.0, then I would have to target the lowest .net Standard that these platforms implement. That being .net Standard 1.3 in this case.

Microsoft have released an easy to view “chart” that tells you which version of each platform implements each version of the standard. You can see it here.

It’s important to note that each platform can implement it’s own features. Windows Phone for example may implement phone specific classes and interfaces, but it will also expose a classes and interfaces of it’s corresponding .net standard.

When Do You Have To Worry About It?

If you are writing for a particular platform, you usually don’t have to worry about .net standard at all. You may at times wish to look up the standard to see what would be coming to your platform next release, but that’s about it.

If you are developing your own library that you wish to be used across multiple platforms, that’s when the .net standard comes in handy. If you write a library that you want working on .net Core, UWP, Windows Phone and .net Framework, you will need to only use classes that are available on all of those platforms. How do you know what classes are available on all platforms? The .net Standard!

What we will likely see in the future from library developers is the requirements changing from “You need .net Framework version 4.6” to, “This is built on top of .net standard 1.6”. And from there you can go and look up what platforms use that standard.

A Web Analogy

Let’s try and think about this in a web sense. It’s not a direct analogy, but we’ll try. Let’s take ECMAScript or Javascript as an example. ECMAScript is a standard. It’s defined in a way that browsers then have to implement. Each browser implements ECMAScript, but they can also do their own things on top (In terms of favourites, addons, plugins etc). This is similar to how a .net platform would work, they implement the standard, but then they can add their own platform specific items on top.

Now if you are writing a website and you wish to use a certain feature of javascript, you have to look at what browsers have implemented that feature. Then you make the decision, either you support “old” browsers, or you only outlay your support for certain modern browsers. This is similar to how it would work if you were writing a .net library. You look at what platforms you wish to support, but if they are old, crusty and are only implementing an old version of the .net Standard, then you can forgo supporting that platform and target a higher standard.

There is one big difference however. Unlike ECMAScript (And other web technologies like CSS), it’s hoped that platforms implement an all or nothing approach when it comes to moving up the .net standard ladder. Either you implement .net Standard 1.5 or 1.6, but you don’t release a platform version that implements 1.5 and a few features from 1.6. Remember, .net Standard is supposed to make it “easy” to determine what classes and interfaces you have available.


I’ll admit, I’m still wrapping my head around how .net standard works. But it’s early days yet. You can go to the Microsoft Github and see people still discussing how things should work long term, so it’s not just your everyday developer trying to work it out. If you have any questions feel free to comment below and I’ll do my best to answer.

Note : This post is for .NET Core version 1.1 or .NET Standard 1.6. At that time, the SmtpClient class had not been ported across. It is now recommended that you use a popular 3rd party library called “MailKit”. You can read our guide on getting up and running with it right here!

You’ve upgraded your latest project to the very latest version of .net core, but you can’t seem to find the correct SMTPClient namespace? It used to live in System.Net.Mail, but it’s just gone *poof*. What gives?

System.Net.Mail Is Not Ported (yet)

If you are on a .net core version 1.1 or less (Or you are working on a .net platform that implements the .net standard 1.6 or less), you will not have access to System.Net.Mail, which by extension means you will not have access to the SmtpClient class, or anything to read POP3/IMAP messages etc. They were not ported across (yet). Bummer!

However, on the Microsoft Github there is a pullrequest here for the port of System.Net.Mail that looks like it made it into .net Standard 2.0. That would point to the next version of .net core having SmtpClient back in. The release date is looking like early 2017.

So In The Meantime?

In the meantime many people are using the MailKit. It’s a very powerful library with a very similar interface/api to the original .net System.Net.Mail. In most cases you should be able to plug it in without too much hassle.

X-XSS-Protection is a header that can be set on a webpage to activate “limited” XSS protection in certain browsers. At the time of writing, the header is available in all modern browsers except Firefox.

If you aren’t up to speed on what XSS is, have a quick read of this wikipedia article first then come back.

Great, now let’s first take a look at what browsers do out of the box. All browsers use static analysis to detect XSS attacks. They are rather vague about how they offer this protection, but usually it’s protecting against the most basic attacks. A good writeup on how Chrome’s protection has evolved over time (And still getting bypassed) can be found here : Hopefully that should give you an idea of the sort of things the browser will natively protect against.

Now usually the browser has the XSS filter turned on by default, but using the header should enforce it. There are also a couple of other values to use to extend the functionality of the header.

X-XSS-Protection Settings

X-XSS-Protection: 0
Disables XSS protection (Handy when you may want to test out XSS on your own)

X-XSS-Protection: 1
Enables XSS protection. If XSS is detected, the browser attempts to filter or sanitize the output, but still renders it for the most part.

X-XSS-Protection: 1; mode=block
Enables XSS protection and if XSS is detected, the browser stops rendering altogether.

X-XSS-Protection: 1; report=<reporting-uri>
Report works only in Chromium browsers (But can be used to enforce protection in other browsers). You can have a callback that lets you know about XSS attempts.

Setting X-XSS-Protection at the Code Level

Similar to adding any other default header to your app, you can add a Use statement to the Configure method in your startup.cs like so :

And you’re done!

Setting X-Xss-Protection at Server level

If you are using IIS or any other web server infront of kestrel, you can also set headers there. There are different requirements for each server.

Setting X-XSS-Protection in IIS

The best way to do this if you are just using IIS to forward requests to Kestrel (Or even if this is actually being hosted in IIS), is to do this in IIS Manager.

  1. Open IIS Manager and on the left hand tree, left click the site you would like to manage.
  2. Doubleclick the “HTTP Response Headers” icon.
  3. Right click the header list and select “Add”
  4. For the “name” write “X-Xss-Protection” and for the value write in your desired option e.g. “1”.

Setting X-XSS-Protection in Apache

In your httpd.conf file you need to append the following line :

Setting X-XSS-Protection in htaccess

Setting X-XSS-Protection in NGINX

In nginix.conf add the following line. Remember to restart the service after!

X-FRAME-OPTIONS is a web header that can be used to allow or deny a page to be iframed. This is very important when protecting against clickjacking attempts. Using this header you can ensure that your content is not rendered when placed inside an IFrame, or only rendered under certain conditions (Like when you are framing yourself).

A common alternative to protect against clickjacking is to use javascript code to “break” iframes when your website is placed in them. This works for the most part but will obviously fail if the user does not have JS enabled, or (more common than you think), you forget to load the JS file on a particular page.

X-Frame-Options Settings

Your options when setting the header as as follows.

The page cannot be put in a frame no matter who it is (Including the site framing itself). If you don’t use frames on your own site then this is a good catch all.

The page can be framed as long as the domain framing it is the same. This is good if you are using frames yourself.

The page can be framed by the specified domains. Good if you have two sites with one framing the other.

Note that Allow-From is only supported in Firefox and IE. Chrome and Safari have both said that they will not support it and instead implement “Content-Security-Policy”, an alternative way to prevent clickjacking (And the subject of a future post!). Because of that it is not recommended you use this setting, stick with DENY or SAMEORIGIN.

Setting X-Frame-Options At The Code Level

Adding X-FRAME-OPTIONS to your .net core app is very simple. In your Configure method in your startup.cs, you need to add a custom middleware like so :

And that’s all! Now every request that runs through your core app will be protected.

Setting X-Frame-Options At The Server Level

You (or your dev ops team) may prefer to configure headers at the server level. In that case below are the various ways to add X-FRAME-OPTIONS to your web server so every request gains the header.


The best way to do this if you are just using IIS to forward requests to Kestrel (Or even if this is actually being hosted in IIS), is to do this in IIS Manager.

  1. Open IIS Manager and on the left hand tree, left click the site you would like to manage.
  2. Doubleclick the “HTTP Response Headers” icon.
  3. Right click the header list and select “Add”
  4. For the “name” write “X-FRAME-OPTIONS” and for the value write in your desired option e.g. “SAME-ORIGIN”.

Setting X-FRAME-OPTIONS in Apache

In your httpd.conf file you need to append the following line :

Setting X-FRAME-OPTIONS in htaccess

If you are using shared hosting you may only have access to an HTAccess file. Or you may prefer to use HTAccess to manage redirects, headers etc anyway. If that’s the case you need to add the following to your .htaccess file.


In nginix.conf add the following line (And restart the nginx service afterwards).

Attempting to install a nuget package the other day I got the following error :

Package ‘xyz’ uses features that are not supported by the current version of NuGet. To upgrade NuGet, see

Following the link takes you to this page. Because I am using the inbuild package manager console from Visual Studio, I followed the steps inside VS that say to go Tools > Extensions and Updates and then click the Updates tab to see if I had an update waiting.

I didn’t. Still stuck. Damn.

After a bit of searching I came across this page that has the Visual Studio extensions to be downloaded manually and installed. After downloading the package and installing manually, with a quick restart of visual studio we are up and running on the latest version of Nuget!

If you are unsure if you are on the latest version of Nuget, you can type “nuget help” in your package manager console and it will tell you the version.

Redis is a high performance distributed cache. It’s great for storing data that you are going to need again and again in a short period of time when you don’t want to use processing power to “create” that data again. Think number crunching or heavy SQL queries for data that doesn’t change often.

Roll Your Own

First off. You can absolutely roll your own Redis Cache services abstracted by your own interfaces etc. You may find it a little difficult to find libraries that target .net Core, but this will change over time.

In saying that, there is a “.net core” way of doing things that is a little different. It does tie you into the framework a little, but it abstracts away the caching completely and let’s Microsoft handle it and that’s what we are going to go over today.

The Core Way

The first thing you need to do is add the Redis caching package provided by Microsoft. You can do this in your package manager console by running :

In your startup.cs, you now need to add the following to your ConfigureServices method. It should look something like :

For your Configuration, while I’ve hardcoded this to, you can obviously change this to pull from your configuration as required. Either from AppSettings/ConnectionStrings etc.

And as you can probably guess with the method signature of “AddDistributedRedisCache”, you can also use things like SQL or InMemory caches using a similar sort of method. We will go over this in future posts!

AddDistributedRedisCache actually adds an interface automagically to your service collection called “IDistributedCache” that you can then use to set and retrieve values. You can then use controller dependency injection to get this anywhere in your app. So say we have a controller called HomeController and it wants to use the RedisCache. It would go :

The first time we view this page, there is nothing in the cache so we are given a new time. And it’s added to the cache. If we refresh the page, we then end up with the time that was cached. So for example :

A couple more notes.

  • IDistributedCache has async methods. You should use these in all scenarios that are possible.
  • IDistributedCache allows for storing either string values or byte values. If you want to serialize an object and store the entire thing, you can either serialize it to bytes and save it as bytes, or serialize it to JSON and save it as a string if you prefer.
  • As discussed earlier, while this is a Redis distributed cache, there are other implementations available that follow the exact pattern for InMemory, SQL Server etc.

If you need to use an InMemory Cache rather than Redis, see our tutorial on In Memory Caching here