X-Frame-Options on its way out?

[SimmeNilsson]

Nice library!
While going through the headers it sets I ran into this on MDN regarding X-Frame-Options.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

Warning: Instead of this header, use the frame-ancestors directive in a Content-Security-Policy header.

If I want to use AddDefaultSecurityHeaders but remove this option do I just call .Remove("X-Frame-Options")?

[andrewlock]

If I want to use AddDefaultSecurityHeaders but remove this option do I just call .Remove("X-Frame-Options")?

I would suggest that instead of doing that, you just customize the set yourself 🙂 The AddDefaultSecurityHeaders are meant to be an easy road in - it's likely you'll want to customize other aspects like the CSP too 🙂

Basically copy this method into your application, rename it, and customize it with whatever works best for you!

[SimmeNilsson]

My humble rationale was that using it and then doing the few modifications I want to do would be similar to forking.
If you then, for example, find a new header that should be included, I would get that the next time I update the package.
While if I copy, I basically take a snapshot and then am on my own. 😅

But is that a bad way of using AddDefaultSecurityHeaders?

[andrewlock]

The mistake is thinking that AddDefaultSecurityHeaders is actually adding recommended security headers. That's not really the case - it adds a set of headers that give you some security that should be applicable for a broad set of applications.

I have considered adding an AddRecommendedSecurityHeaders which is much more locked down, but the reality is that would basically work for noone 😅 For example, the CSP should be much more locked down ideally, but you have to tailor that to your specific application. It also depends a lot what type of application you have - Razor Pages/Blazor/Web API etc. Each of those have different header requirements as to what you can lock down.

For general advice about security headers, I suggest checking the OWASP advice. You can also run your site against https://securityheaders.com/ and see what headers they suggest 🙂

[SimmeNilsson]

Got it! Thank you. 👍

May I take this opportunity to ask a final (although unrelated) question?
How should one think about the header footprint?
Your documentation mentions configuring different policies depending on endpoint.
Is it a bad idea to configure it based on response type instead?
Thinking non-page responses could be more lightweight across the board.

[andrewlock]

Sorry, missed your final question!

How should one think about the header footprint?
Your documentation mentions configuring different policies depending on endpoint.
Is it a bad idea to configure it based on response type instead?

So, the library used to take this approach. But the tl;dr; is I moved away from this for a few reasons:

1. Properly handling content-types is a bit harder than you might expect. Some file types should have "document" level headers for example, that you might not consider. And considering all the "+" mime types gets a bit more complex.
2. OWASP recommends you apply restrictive headers to these content-types anyway, so you don't actually reduce the header size if you want to be "most secure", you just lock things down for longer
3. I'd recommend splitting your endpoints by functionality where possible e.g. api vs razor pages, in which case configuring based on endpoint/group should give you roughly the same split.

Overall, it's up to you 🙂 I would err on the side of safety first - if you need the performance, consider tweaking!