安全性
Q17：使用Ajax，是否让网站曝露在更高的风险中？
答：所谓Ajax，最狭义的说法是指非同步传输的沟通方式，也就是使用XMLHttpRequest这个浏览器物件来处理用户端与伺服器端资料交换的过程。就通用说法而言，Ajax进一步包含了使用JavaScript操作CSS与DOM（文件物件模型），以呈现丰富的视觉效果。因此Ajax的技术早已存在，它就是JavaScript，而Ajax只是一种应用的观念。
JavaScript本身是用户端的程式语言，是在网站使用者的电脑中执行，不像伺服器端的脚本程式，因此对网站本身造成威胁的机会极低。
有些人认为Ajax程式能够透过检视程式码的方式看到它的程式逻辑与变数使用方式，而增加对网站的攻击面，不像伺服器端的程式，能隐藏程式语法。
事实上，一个安全的网站，原本就必须在前端资料传递到后端时，做好过滤与把关的工作，不要相信前端传来的东西，这是一个网站开发人员必须牢记在心的金科玉律。如果伺服器端程式在设计时能谨守本份，重视程式的安全规画，那么无论前端是由使用者输入资料传来的，或是由JavaScript程式传递而来，都一样安全。
反而是由伺服器端发展出来的Ajax解决方案，例如DWR，能让使用者能从前端程式使用后端Java语法，即可能有潜在的安全威胁。
Q18：使用XMLHttp Request进行非同步传输时，难道没有潜在风险？
答：事实上，浏览器在设计这个物件之初，就已经考量到安全性的问题，因而限制XMLHttpRequest请求的资源与呼叫的脚本程式，两者必须在同一个网域内，不能存取网域外的资源，借此降低风险。这可避免恶意程式任意抓取资料，或是上传具危险性的程式给其他伺服器执行。
不过Web 2.0盛行的混搭（Mashup）方式，透过开放API进行资料交换，而这种方式的确就是绕过同一网域的限制，会产生一定的风险。设计这类API时，必须特别注意它的存取限制，以免让骇客有机可趁。
Q19：Ajax会向伺服器频繁要求资讯，是否会对网站形成阻断式攻击（Denial of Service）的效应？
答：就Ajax的设计模式而言，的确向伺服器发出要求的次数将会增加，往往一点异动，就会与网页伺服器或资料库互动，尤其互动效果越多，更是如此。
就拿Google搜寻时会采用自动完成的功能，列出可能的搜寻关键字，或是雅虎奇摩的字典查询服务，也有相似设计，只要输入文字，便会向伺服器要求待选字。
这个安全性问题应该就两个层面来看。首先应用这类Ajax语法时，原本就必须做好效能考量与测试，例如善用快取功能，记录反覆查询高的关键字，反而能降低伺服器的负担。
其次，如果骇客打算使用DoS对一个网站发动攻击时，事实上无论是不是采用Ajax都一样，而且利用Ajax发动DoS，不见得是有效率的作法。
Q20：如果Ajax对伺服器端的危害有限，那么对用户端呢？
答：虽然采用Ajax进行非同步传输时会受到本地端的限制，提供了一定的安全性，然而由于采用JavaScript，便会让使用者遭到跨站脚本攻击（Cross-Site Scripting，XSS）的机会增加，而让骇客可以趁机窃取使用者的帐号资讯或殖入恶意程式到使用者的电脑中。
过去使用者还可以透过关掉JavaScript方式，以降低浏览网站时的风险，不进入Ajax网站关掉JavaScript，形同使用者拒绝进入该网站，因为基本功能都无法使用。
由这观点来看，的确Ajax盛行，让骇客更有机会透过XSS的手法侵害使用者，不过XSS之所以能成功，通常是网站本身已经存在资安防线上的漏洞，例如没有检查使用者上传的资料，或是应用程式、系统本身有漏洞，如果能做好这些资安防护，那么即使采用再多的Ajax功能，使用者一样安全无虞。
