XmlHttpRequests (or “ajax“) is generally considered to be safe because it is restricted by the “same origin” policy, but that isn’t entirely correct. Consider the following: an ajax-call, like all http communication, consists of a request and a response. For read-operations the response is needed, for write-operations … that ain’t necessarily so!
So how can a “hacker” send a request for such a write-operation and have it executed (which amounts to “cross site request forgery” actually)? There’s a number of possibilities:
- Execute a GET-request by including it in the attack-site html as the src of a script, css or img tag, for all of which the same origin-policy does not apply.
- Using JavaScript to create a form, populate it and POST it, the same-origin policy does not apply to forms being posted.
- Just do a normal XHR-request, the same-origin policy applies, but some top-notch browsers will execute the request and just ignore the response (is that a bug or a feature?)
Conclusion: if you want to do anything more than read-requests on the same domain, you really-really-really have to protect your resources against CSRF using one of the techniques that are described in this wonderful OWASP CSRF cheat-sheet.