XSS Prevention
Encoding should be your first line of defense against XSS, because its very purpose is to neutralize data so that it cannot be interpreted as code. In some cases, encoding needs to be complemented with validation. This encoding and validation should be outbound, because only when the input is included in a page do you know which context to encode and validate for.
As a second line of defense, you should use inbound validation to sanitize or reject data that is clearly invalid, such as links using the javascript: protocol. While this cannot by itself provide full security, it is a useful precaution if at any point outbound encoding and validation is improperly performed due to mistakes or errors.
If these two lines of defense are used consistently, your website will be protected from XSS attacks. However, due to the complexity of creating and maintaining an entire website, achieving full protection using only secure input handling can be difficult. As a third line of defense, you should also make use of Content Security Policy (CSP).
more info
防御XSS最佳的做法就是对数据进行严格的输出编码，使得攻击者提供的数据不再被浏览器认为是脚本而被误执行。例如 <script> 在进行HTML编码后变成了<script>，而这段数据就会被浏览器认为只是一段普通的字符串，而不会被当做脚本执行了。
编码也不是件容易的事情，需要根据输出数据所在的上下文来进行相应的编码。例如刚才的例子，由于数据将被放置于HTML元素中，因此进行的是HTML编码，而如果数据将被放置于URL中，则需要进行URL编码，将其变为 %3Cscript%3E。此外，还有JavaScript编码、CSS编码、HTML属性编码、JSON编码等等。好在现如今的前端开发框架基本上都默认提供了前端输出编码，这大大减轻了前端开发小伙伴们的工作负担。
其他的防御措施，例如设置CSP HTTP Header、输入验证、开启浏览器XSS防御等等都是可选项，原因在于这些措施都存在被绕过的可能，并不能完全保证能防御XSS攻击。不过它们和输出编码却可以共同协作实施纵深防御策略。
Reference
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet