1、基于特征的防御
XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同。这就给XSS漏洞防御带来了困难：不可能以单一特征来概括所有XSS攻击。
传统XSS防御多采用特征匹配方式，在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击，采用的模式匹配方法一般会需要对“javascript”这个关键字进行检索，一旦发现提交信息中包含“javascript”，就认定为XSS攻击。这种检测方法的缺陷显而易见：骇客可以通过插入字符或完全编码的方式躲避检测：
躲避方法1)在javascript中加入多个tab键，得到
< IMG SRC=”jav ascript:alert(‘XSS’);” >;
躲避方法2) 在javascript中加入(空格)字符，得到
< IMG SRC=”javascri pt:alert(‘XSS’);” >;
躲避方法3) 在javascript中加入(回车)字符，得到
< IMG SRC=”jav
ascript:alert(‘XSS’);” >;
躲避方法4)在javascript中的每个字符间加入回车换行符，得到
< IMG SRC=”javascrip\r
\nt:alert(‘XSS’);” >
躲避方法5)对”javascript:alert(‘XSS’)”采用完全编码，得到
< IMGSRC=javascrip?74:alert(‘XSS’) >
上述方法都可以很容易的躲避基于特征的检测。
2、基于代码修改的防御
和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种方法就是从Web应用开发的角度来避免：
步骤1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。
步骤2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
步骤3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag(没有javascript)，去掉任何对远程内容的引用(尤其是样式表和javascript)，使用HTTP only的cookie。
当然，如上操作将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。
3、client xss 攻击
Client XSS攻击发生，由于不信任的数据被用来更新DOM，使用非安全的JS接口。
最早最强壮的防御方法：
Using safe JavaScript APIs（使用安全的JS接口）
4、server xss攻击
Sever XSS是由HTML中包含了不可信的数据导致。大多数情况下， 也是最早的最强大的防御方法是
Context-sensitive s输入校验 或者 数据清洗 也可以帮助预防此类攻击， 但是此法困难更加多很多， 比输出转码方法。erver side output encoding （服务器端转码）
