== XSS Defense


=== Why?
Hopefully we've covered that by now. Bottom line, you don't want someone else's code running in the context of your users and their logged-in session

=== What to encode?
The basic premise of defending against XSS is *output encoding* any untrusted input that goes to the screen.
That may be changing with more sophisticated attacks, but is still the best defense we currently have. *AND* ... *context matters*

Another word on 'untrusted input'. If in doubt, treat everything (even data you populated in your DB as untrusted).
Sometimes data is shared across multiple systems and what you think is your data, may not have been created by you/your team.

=== When/Where?
Encode *as the data is sent to the browser* (not in your persisted data).  In the case of *Single Page Apps (SPA's), you will need to encode
in the client*. Consult your framework/library for me details, but some resources will be  provided on the next page.

=== How?

 * Encode as HTML Entities in HTML Body
 * Encode as HTML Entities in HTML Attribute
 * Encode for Javascript if outputting user input to javascript (but think about that ... you're outputting user input into javascript on your page!!)

*DO NOT* try to blacklist/negative filter on strings like '<script>' and so forth.


...See the next page for some recommended resources and reading on Defending against XSS