search

getkirby / ideas

This is the backlog of ideas and feature requests from the last two years. Use our new feedback platform to post your new ideas or vote on existing ideas.
https://feedback.getkirby.com
20 stars 0 forks source link

Automatically set `X-Frame-Options: deny` #405

Open hdodov opened 5 years ago

hdodov commented 5 years ago

We just received a warning that our Kirby 2 site was prone to clickjacking attacks due to a missing header. I can see that this header is missing in Kirby 3 too. Perhaps it's a good idea for Kirby to add it by default.

More info on MDN.

distantnative commented 5 years ago

Just thinking out loud: Aren't there cases where a developer wants their site to be includable in an iframe? Setting this header by default would probably send them on a long searching spree before they realize why it is not working.

hdodov commented 5 years ago

I don't think so. If the iframe is blocked, the browser will log an error with the reason, i.e. the header. Then you search "kirby remove iframe header" and you're done. Prehaps Access-Control-Allow-Origin can also be set by Kirby by default.

If you don't want those security headers set, you disable secureHeaders in config.php. Although this might seem overly paranoid, that's a good thing when it comes to security, I think.

It comes down to which of these two scenarios is better:

  1. I'm a developer and I need to figure out how to point an iframe to the site
  2. I'm a client and I wonder why my site was attacked
lukasbestle commented 5 years ago

I agree with @distantnative. The header makes sense for most sites, but for some it's not wanted.

Kirby's philosophy has always been to have sane defaults, but always so that people can add stuff they need and rarely need to remove stuff they don't need (which is how some other CMS like the popular one that starts with Word and ends with Press work).

I think we should add this to our security guide though.

PS: Access-Control-Allow-Origin works the other way around: You get the secure behavior if you don't include it. By including it, you explicitly whitelist an origin that would otherwise be blacklisted.

hdodov commented 5 years ago

I like the Kirby philosophy, but when it comes to security, I think the sane defaults are the most secure ones. I remember reading somewhere that @bastianallgeier values security a lot. Perhaps he can shed some light on that.

If you choose the less secure path, you'll likely know of the problem when it's too late and most importantly, when you'd probably have no way of turning things back. If someone stole someone else's information, putting a header on your site won't revert that.

On the other hand, chosing the more secure path would require you to do just a little bit of research and implement what you want. No damage done, nothing compromised. If you put this in the docs, as @lukasbestle mentioned, this would be even easier to deal with. And all of that for a use case that, in my opinion, is niche.

lukasbestle commented 5 years ago

I like the Kirby philosophy, but when it comes to security, I think the sane defaults are the most secure ones. I remember reading somewhere that @bastianallgeier values security a lot. Perhaps he can shed some light on that.

We do value security a lot. It's very high on our priority list, if not at the top.

This is however something that belongs in the server configuration, not in the CMS configuration. For example the hosting provider Uberspace, which I value a lot, sets the header by default.

I understand your arguments and I agree that it makes sense to have the more secure option by default, but to be honest it just feels wrong to set the header from the CMS.