In this specific case merely forging a POST request externally does nothing as the user has to be signed in for this to work. Thus, restricting actions such as voting to POST (and restricting to same-origin) does constitute adequate protection if there is no XSS vulnerability on the site.

But if the user IS signed in (and if someone arrives at your site from a link on Hacker News there's a very good chance they will be signed in) a POST forged from your site can affect their session. Read up on CSRF - it's a very different vulnerability from XSS (though having an XSS vulnerability will make any CSRF protection you have in place null and void).

http://en.wikipedia.org/wiki/CSRF

Don't be so condescending, you didn't read my entire post. To quote myself:

  > POST (and restricting to same-origin)

I still don't think it's possible to forge the referer header on an uncompromised browser.

Would restricting to same-origin break http://hackerne.ws?

Or xhr with custom header, if you don't want to have to keep track of state.

So that anyone who has JavaScript disabled will be treated like an attacker? No thanks, HN is one of very few sites nowadays that work fine without JavaScript tricks, and I'd much rather PG kept it that way.

A custom header is not sufficient (blame Flash): http://lists.webappsec.org/pipermail/websecurity_lists.webap...