Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

nosniff should be set non html content as well #40

Closed
mkristian opened this Issue · 1 comment

2 participants

@mkristian

when recently switched my first application to use rack-protection I realized that the only difference is that
X-Content-Type-Options: nosniff
was missing.

since security issues are always on move my understanding of things is limited. butwhen I looked into the code

https://github.com/rkh/rack-protection/blob/master/lib/rack/protection/xss_header.rb#L28

then it shows that the header is only set with html content.

I was thinking about it a while and personally I find it difficult to construct a usecase where the server sends non html with a html content-type - then only the nosniff would make sense for the browser. maybe I misunderstand (most probably) what exactly the header triggers inside the browser. even if the header does apply to child components of an html page I have the feeling that the header should be applied to all request. image url can be embedded with any email, i.e. living outside of any html context and there the image can be "evil" javascript or so and the browser should not execute the javascript.

finally I looked how google handles such isolated image url (see response headers):

https://ssl.gstatic.com/ui/v1/icons/mail/themes/planets/bg_venus_1050x600.jpg

and yes they do send the nosniff option !!
it is no good argument: just do it as google does. but adding an extra header does not harm either and it feels to be on the save side of things.

again looking at the logic of code, it looks like with option[;nosniff] to be false there will be no x-xss-protection ! again my same argument just send those headers. maybe the x-xss-protection should be able to be switched off via option[;xss-protection] or via option[:xss_mode] == false or nil

I can prepare a pull request if there are no objections to "be secure" by default and have more symmetric options to turn off either of those headers.

@rkh rkh closed this in c823079
@mkristian

thanx for the fix. hope I see a release before my current project goes public ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.