Oh, the irony. I protect myself from XSS with NoScript. Which prevents me from reading the text of this article.

Way to not fallback gracefully.

Was going to say the same thing, At least get your stuff showing more than a blank page- Sheesh.

In firebug, remove the first html > head > style element:

   <style> body { display : none;} </style>

or Firefox menu -> View -> Page Style -> No Style

Good stuff but not really a cheat sheet...

XSS prevention cheat sheet:

1) Never send untrusted data to the client.

How you do that isn't terribly important. It just matters that you do. Which is what that page is talking about: what you can do in order to never send untrusted data to the client.

Web developers would love it if there was a paragraph explanation that could explain how to prevent all XSS vulnerabilities in every site in detail, but there isn't.

That's excellent! We can pair that with the other prevention cheat sheet:

1) Never trust what the client sends you.

AKA "How to prevent SQL injection and other such nasties"

These are the two least-useful pieces of advice in software security. Everyone has heard them, nobody is secure.

Great counter-indication of software security: "We have no SQL injection. No way. You'd get fired." What that tells me? You're not looking out for SQL injection; you think it can't happen.

Someone here--it may have been you--highlighted this problem once as the difference between a diet that works and public policy on diet that works. If you actually follow the (security guidelines|diet), you'll be good; but naively telling people has very little effect.

You can lead a horse to water, but you can't make it drink.

Actually, that's not entirely correct. It should be:

1) escape data to prevent it from being interpreted as code

Because this security problem is just subset of markup correctness problem.

If you escape data perfectly, then both trusted and untrusted data won't be misinterpreted, e.g. I can echo any evil input if my character encoding is enforced and HTML special chars are escaped as entities. I can send any untrusted nastiness to database via prepared SQL statement.

> escape data to prevent it from being interpreted as code

What about too much data? Overflow is a concern, too. Escaping is just one solution, so I shot for the more general rule.

> What about too much data? Overflow is a concern

Buffers are not supposed to overflow with trusted data either, so again, security is subset of correctness. "Not trusting" data only prevents exploit from reaching vulnerable code, it doesn't fix the vulnerability.

Don't write web applications C? ;)

"e.g. I can echo any evil input if my character encoding is enforced and HTML special chars are escaped as entities."

FAIL :-P

AFAIK You need to JS escape anything that goes into a JS context too.

You're right - escaping is very dependent on context, and sometimes you need to escape data multiple times in nested contexts.

In inline script you need to get JS string escaping right and avoid </ sequence that ends HTML CDATA.

And if you send that data from JS to the server, you cannot rely on the theory that JS massaged that data first.

Absolutely right.

It might be nice to call this useful document something else, though. "XSS prevention summary" or whatever.

Isn't this better? http://ha.ckers.org/xss.html

No, that is an XSS exploitation (juxtapose: prevention) cheat sheet.

This is why I shouldn't come on the Internet in the morning, I simply cannot parse words correctly. Sorry.

that's exactly what i was expecting. thanks!