334 Part II: Developing an Ajax Library
Summary
There is no such thing as absolute security. Ultimately, all locks can be broken and all
countermeasures defeated. However, this does not mean useful measures cannot be employed
to provide reasonable and adequate security for Web applications. The majority of security
topics presented in this chapter are not necessarily unique to Ajax. Most of the exploits seen
are a direct result of Web developers being far too trusting, revealing information they should
not, forgetting to be strict in checking their inputs for malicious information, and avoiding
sanitizing any output they may deliver. If you filter inputs, sanitize outputs, check requests,
and avoid information disclosure, you will go a long way in securing your Web application.
Ajax does not change this. What Ajax changes is an interest level in attacking JavaScript, so we
spent more time discussing those exploits that rely on it such as XSS and CSRF. Most of these
ideas can be addressed, but what is interesting about them is that in many cases a third-party
site was involved. Consider that the only real achievable goal is to improve your own security
posture, and as soon as you start interacting with other sites such as relying on their data via a
Web service, your security posture may be compromised. To this end, you are highly
encouraged to think twice about consuming remote data and to do so cautiously and within a
sandboxed environment. Not to be an alarmist, but on the Web, you really should not trust
anyone but yourself. In the next chapter, it is finally time to move away from the drier topics
of delivery and security and present information on interface conventions that should be used
in Ajax applications.FIGURE 7-17 Be careful when making remote script and JSON requests.