2.1.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') >
上述方法都可以很容易的躲避基於特征的檢測。而除了會有大量的漏報外，基於特征的
還存在大量的誤報可能：在上面的例子中，對上述某網站這樣壹個地址，由於包含了關鍵字“javascript”，也將會觸發報警。
2.1.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 綜論
XSS攻擊作為Web業務的最大威脅之壹，不僅危害Web業務本身，對訪問Web業務的用戶也會帶來直接的影響，如何防範和阻止XSS攻擊，保障Web站點的業務安全，是定位於業務威脅防禦的入侵防禦產品的本職工作。