隨著Google 推出Gmail之後，新的網頁體驗讓所有使用者眼睛一亮，開始注意到Ajax技術，而且在新一代的網站開發上常被使用。如果開發網頁時需應用到Ajax，該怎麼考量安全性？
所謂Ajax（Asynchronous JavaScript and XML），最狹義的說法是指非同步傳輸的溝通方式，也就是使用XMLHttpRequest這個瀏覽器物件來處理用戶端與伺服器端資料交換的過程。就通用說法而言，Ajax進一步包含了使用JavaScript操作CSS與DOM（文件物件模型），以呈現豐富的視覺效果。因此Ajax的技術早已存在，它就是JavaScript，而Ajax只是一種應用的觀念。

JavaScript本身是用戶端的程式語言，是在網站使用者的電腦中執行，不像伺服器端的腳本程式，因此對網站本身造成威脅的機會極低。

有些人認為Ajax程式能夠透過檢視程式碼的方式看到它的程式邏輯與變數使用方式，而增加對網站的攻擊面，不像伺服器端的程式，能隱藏程式語法。

是否讓網站曝露的程度更大？
事實上，一個安全的網站，原本就必須在前端資料傳遞到後端時，做好過濾與把關的工作，不要相信前端傳來的東西，這是一個網站開發人員必須牢記在心的金科玉律。如果伺服器端程式在設計時能謹守本份，重視程式的安全規畫，那麼無論前端是由使用者輸入資料傳來的，或是由JavaScript程式傳遞而來，都一樣安全。

反而是由伺服器端發展出來的Ajax解決方案，例如DWR，能讓使用者能從前端程式使用後端Java語法，即可能有潛在的安全威脅。

進行非同步傳輸時的潛在風險
答：事實上，瀏覽器在設計這個物件之初，就已經考量到安全性的問題，因而限制XMLHttpRequest請求的資源與呼叫的腳本程式，兩者必須在同一個網域內，不能存取網域外的資源，藉此降低風險。這可避免惡意程式任意抓取資料，或是上傳具危險性的程式給其他伺服器執行。

不過Web 2.0盛行的混搭（Mashup）方式，透過開放API進行資料交換，而這種方式的確就是繞過同一網域的限制，會產生一定的風險。設計這類API時，必須特別注意它的存取限制，以免讓駭客有機可趁。

有可能形成類似DoS攻擊的效應？
Ajax會向伺服器頻繁要求資訊，是否會對網站形成阻斷式攻擊（Denial of Service）的效應？就Ajax的設計模式而言，的確向伺服器發出要求的次數將會增加，往往一點異動，就會與網頁伺服器或資料庫互動，尤其互動效果越多，更是如此。

就拿Google搜尋時會採用自動完成的功能，列出可能的搜尋關鍵字，或是雅虎奇摩的字典查詢服務，也有相似設計，只要輸入文字，便會向伺服器要求待選字。

這個安全性問題應該就兩個層面來看。首先應用這類Ajax語法時，原本就必須做好效能考量與測試，例如善用快取功能，記錄反覆查詢高的關鍵字，反而能降低伺服器的負擔。

其次，如果駭客打算使用DoS對一個網站發動攻擊時，事實上無論是不是採用Ajax都一樣，而且利用Ajax發動DoS，不見得是有效率的作法。

用戶端安全
如果Ajax對伺服器端的危害有限，那麼對用戶端呢？

雖然採用Ajax進行非同步傳輸時會受到本地端的限制，提供了一定的安全性，然而由於採用JavaScript，便會讓使用者遭到跨站腳本攻擊（Cross-Site Scripting，XSS）的機會增加，而讓駭客可以趁機竊取使用者的帳號資訊或植入惡意程式到使用者的電腦中。

過去使用者還可以透過關掉JavaScript方式，以降低瀏覽網站時的風險，不過存取Ajax網站，使用者電腦的瀏覽器如關掉JavaScript，形同拒入該網站，因為該站的基本功能都將無法使用。

由這觀點來看，Ajax盛行，的確讓駭客更有機會透過XSS的手法侵害使用者，不過XSS之所以能成功，通常是網站本身已經存在資安防線上的漏洞，例如沒有檢查使用者上傳的資料，或是應用程式、系統本身有漏洞，如果能做好這些資安防護，那麼即使採用再多的Ajax功能，使用者一樣安全無虞。文⊙黃天賜

開發Ajax的10大守則
1.前、端後都要做好安全的把關工作
2.盡量以HTTP POST方法傳輸資料
3.不要直接用eval函式喚起JSON物件
4.限制使用者可用的HTML語法
5.禁止可留言的網頁頁面使用JavaScript語法
6.使用Ajax框架，必須注意安全性問題
7.讓使用者知道自己身處的狀況
8.保持小量傳輸
9.注意易用性與內容的平衡
10.優雅降級原則