Hacker News Reader

Comment by tzury | Hacker News Reader

Does your solution assumes referrer will not be manipulated on the client side?

I imagine it assumes a header like X-Requested-By has not been manipulated. You can safely assume that the referrer, or other headers, have not been manipulated. There is no way for malicious Javascript running in the users browser to edit headers.

Of course, anyone can code their own browser to lie about headers. It doesn't make much sense to specifically open yourself to vulnerabilities though.

exactly. since normal script-tag cannot drop new X-Requested-With header, there's no need to add some "while(1)" things which look ugly.

There's downside, though - you can't inspect JSONs by simply opening them in a new tab.

my solution is request.xhr? check. the link above is only to explain what rails-bug was. I don't think checking referrer is a good idea there.

Sorry Egor, I thought you are pointing out an article you have published.

This is joev's article. His explanations of the issue are better than mine ;)

Hey Egor, article author here. How come you are not such a fan of checking referer? It cannot be a global fix (some sites depend on serving xdomain scripts, have lots of users with proxies that alter headers etc), but it should work well for many cases no?

it works of course, but to be compatible with many environments we need something more reliable than Referrer.

Reply on news.ycombinator.com