Loading…
Introduce default_headers. closes #6311 #6515 #7302
10 participants
@homakov Thank you. Could you add some tests?
@rafaelfranca thanks, here they are
So, it's now considered not best practice to use the X-* pattern when minting new HTTP headers: http://tools.ietf.org/html/rfc6648
@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.
offtopic: random thoughs on security headers http://homakov.blogspot.com/2012/06/saferweb-with-new-features-come-new.html
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.
@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.
Ah! Then continue. I thought they were something new you were making. No worries. TIL.
+1 These are great defaults that everyone will probably want turned on.
+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.
Seems good. Thanks @homakov!
Can we have better commit messages next time? As showed here: http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#commit-your-changes
@drogus my bad, forgot that commit message is what i write in -m and not in title of PR.
@tenderlove Spasibo :)
|
I don't think these configs should be in config/application.rb, but rather in the action dispatch railtie.
homakov
added a note
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
|
Can we have a CHANGELOG entry for this?
@spastorino do we still add changelog changes in PRs? :) You can add it if dont mind
@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 ;).
pushed 0b11dbe
@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.
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.
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?
@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 :(
@homakov @spastorino @josevalim Just submitted a pull request to add the X-Content-Type-Options header.
@homakov @aantix what about the rest of the headers described in http://recxltd.blogspot.com/2012/03/seven-web-server-http-headers-that.html ?
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.
@spastorino they should be per-app configured.. up to developers.
Yeah, so could be nice to document about them and that as a developer you could change default_headers if you want to.
@spastorino I will manage it. As those are mostly security-related headers I want to update this document http://guides.rubyonrails.org/security.html
@homakov sure, go ahead
@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 :) )
@homakov 
you're free to push that to docrails
@spastorino yes i pushed :) Just want to see it "here":http://guides.rubyonrails.org/security.html
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.
Also, you will see it "here":http://edgeguides.rubyonrails.org/security.html when docrails changes get merged in master.
@steveklabnik @frodsan got it, no rush.
I think mass assignment section also will need to get updated when we get strong_parameters merged.
@spastorino @homakov I added some clarifications to the security documentation surrounding what the default values are and how to clear them.
@spastorino Merged in my changes.
| @@ -41,6 +41,11 @@ class Application < Rails::Application | ||
| # Configure sensitive parameters which will be filtered from the log file. | ||
| config.filter_parameters += [:password] | ||
| + config.action_dispatch.default_headers = { | ||
|
I don't think these configs should be in config/application.rb, but rather in the action dispatch railtie.
homakov
added a note
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
|
||
| + 'X-Frame-Options' => 'SAMEORIGIN', | ||
| + 'X-XSS-Protection' => '1; mode=block' | ||
| + } | ||
| + | ||
| # Use SQL instead of Active Record's schema dumper when creating the database. | ||
| # This is necessary if your schema can't be completely dumped by the schema dumper, | ||
| # like if you have constraints or database-specific column types. | ||
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