nosniff should be set non html content as well #40

mkristian opened this Issue Jan 18, 2013 · 1 comment


None yet

2 participants


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

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):

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 added a commit that closed this issue Mar 1, 2013
@rkh rkh rework protection headers, fixes #40 c823079
@rkh rkh closed this in c823079 Mar 1, 2013

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

@zzak zzak pushed a commit that referenced this issue Aug 12, 2016
@rkh rkh rework protection headers, fixes #40 65cf3fd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment