Introduce default_headers. closes #6311 #6515

[homakov]

4.0 feature, everybody agreed to merge it.
Default headers are really useful for various security options and mitigations.

discuss: should we add "Sniff content type" header

[rafaelfranca]

Related with #6311 and #6515 (commenting since github doesn't link issues at the title)

[rafaelfranca]

@homakov Thank you. Could you add some tests?

[homakov]

@rafaelfranca thanks, here they are

[rafaelfranca]

cc/ @NZKoz @tenderlove @josevalim

[steveklabnik]

So, it's now considered not best practice to use the X-* pattern when minting new HTTP headers: http://tools.ietf.org/html/rfc6648

[homakov]

@steveklabnik yea have seen it and lold :) this 'over standardizing' looks funny.

You sure all browsers support Frame-Options along X-Frame-Options? if yes I will change it.

[homakov]

offtopic: random thoughs on security headers http://homakov.blogspot.com/2012/06/saferweb-with-new-features-come-new.html

[steveklabnik]

Is 'X-Frame-Options' an existing header, or a new one? I'm not super familiar with security issues.

If it's old, then obviously, we use it verbatim. If 'browser support' means do browsers can handle a new header without the X- prefix, then yes, as far as I know, they all do.

[homakov]

@steveklabnik yes, both X- headers are extremely old so we hardly can remove 'X-' prefix.
X-XSS-Protection controls built in IE and Chrome anti xss auditor.
X-Frame-Options detects should website be visible in iframes or not. 99% of websites don't need to be shown in iframes.

[steveklabnik]

Ah! Then continue. I thought they were something new you were making. No worries. TIL.

[et]

+1 These are great defaults that everyone will probably want turned on.

[aantix]

+1 We're currently manually adding these defaults for the current client I am working with. It's coupled with complimentary frame busting code, but that's probably a separate story.

[homakov]

@aantix regards framebusting - make sure you use "modern framekiller" when page is hidden by default and then shown if everything is ok. other framekillers don't work.

c'mon, merge or die trying

[tenderlove]

Seems good. Thanks @homakov!

[homakov]

@drogus my bad, forgot that commit message is what i write in -m and not in title of PR.

@tenderlove Spasibo :)

[josevalim]

I don't think these configs should be in config/application.rb, but rather in the action dispatch railtie.

[homakov]

IMO this is a perfect place. Developer sees clearly where and how default headers are defined. Also, how is he supposed to remove them if he doesn't need Frame-Options? We cannot "hardcode" these values.

[josevalim]

config.action_dispatch.default_headers.clear would clear them. Rails has many defaults, we don't list them all on config/application.rb for a reason. Documentation solves the problem of knowing what is on by default and how to clear it.

[spastorino]

Can we have a CHANGELOG entry for this?

[homakov]

@spastorino do we still add changelog changes in PRs? :) You can add it if dont mind

[spastorino]

@homakov we shouldn't be merging PRs without CHANGELOG entries or we should merge and add CHANGELOG entries later but I prefer asking contributors for that. I have merged things without CHANGELOG entries but I don't consider that a good practice anyway. I'm guilty too ;).

[spastorino]

pushed 0b11dbe

[homakov]

@spastorino thannnkss :)

@josevalim i see your point but cannot do so. Explicit definition here looks like common sense to me.

for example we have config.filter_parameters += [:password] but we also could have it built in and ask developers to write config.filter_parameters -= [:password] if they don't want to filter passwords. It is a bit 'monkey patching'. Please, let's leave it as is, I think it's a better option.

[drogus]

To confirm how should we deal with CHANGELOG entries, I've pushed a commit describing it to contributing guide: adf3ea3 I'm serial offender, too, and I probably haven't added CHANGELOG entries to a lot of things myself, but just as with commit messages, I would like to hold any PR that needs fixing this - it may make merging harder and this green button is really tempting, but as we have more commiters and more commits in general, it will be much easier to deal with it this way.

[spastorino]

Is there a reason for not adding also "X-Content-Type-Options" => "nosniff" ?.
@homakov what about the other headers you proposed in the first place?

[homakov]

@spastorino we should add it too. Yet another header to make IE less mad. Go ahead, it can be default :)

Also, if you will write a tutorial, you can find default_headers feature useful for Access-Control-Allow-Origin and X-Content-Security-Policy which are popular headers(http://recxltd.blogspot.com/2012/03/seven-web-server-http-headers-that.html)

@josevalim now I can see values hardcoded inside of ActionDispatcher. It's OK, but i'm afraid that people will get broken framing by updating rails to 4 ver. They will be surprised :(

[aantix]

@homakov @spastorino @josevalim Just submitted a pull request to add the X-Content-Type-Options header.

#7390

[spastorino]

@homakov @aantix what about the rest of the headers described in http://recxltd.blogspot.com/2012/03/seven-web-server-http-headers-that.html ?

[aantix]

I don't think any of the other headers, (Cache-Control, X-Content-Security-Policy, Strict-Transport-Security, Access-Control-Allow-Origin) should have defaults.

[homakov]

@spastorino they should be per-app configured.. up to developers.

[aantix]

My comment above agrees with @homakov

[spastorino]

Yeah, so could be nice to document about them and that as a developer you could change default_headers if you want to.

[homakov]

@spastorino I will manage it. As those are mostly security-related headers I want to update this document http://guides.rubyonrails.org/security.html

[spastorino]

@homakov sure, go ahead

[aantix]

@homakov Let me know if you want any help.

[homakov]

@spastorino @aantix guys pls have a look at https://github.com/lifo/docrails/pull/108/files
I described the most common headers. if you wish to add some more headers - welcome. (and, yeah, welcome to fix my grammar :) )

[spastorino]

@homakov 👍 you're free to push that to docrails

[homakov]

@spastorino yes i pushed :) Just want to see it "here":http://guides.rubyonrails.org/security.html

[steveklabnik]

Well it won't be out on that page until a release. And since this went into master, that'd be the release of Rails 4.

[frodsan]

Also, you will see it "here":http://edgeguides.rubyonrails.org/security.html when docrails changes get merged in master.

[homakov]

@steveklabnik @frodsan got it, no rush.
I think mass assignment section also will need to get updated when we get strong_parameters merged.

[aantix]

@spastorino @homakov I added some clarifications to the security documentation surrounding what the default values are and how to clear them.

https://github.com/lifo/docrails/pull/109

[spastorino]

@aantix as @fxn told you, please push the changes directly to docrails, everyone has commit bit there :)

[aantix]

@spastorino Merged in my changes.