A3:2021 | Cross Site Scripting Mitigation (2) | Cycubix Docs

XSS defense

Why?

Hopefully, we have covered that by now. Bottom line, you do not 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 to the screen. That may be changing with more sophisticated attacks, but it 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 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 are 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