I’ve been pretty aware of the risks of SQL injection and am militant about keeping my database interactions clean. Mark Jaquith today reminded me about the need to make sure my browser output is filtered through clean_url(), sanitize_url(), and attribute_escape(). Furthermore, we all need to remember current_user_can(), check_admin_referer(), and nonces.

The Mozilla docs on JavaScript security give a hint of hope that signed scripts will work around the cross-domain script exclusions that all good browsers enforce. But an item at DevArticles.com throws water on the idea:

Signed scripts are primarily useful in an intranet environment; they’re not so useful on the Web in general. To see why this is, consider that even though you can authenticate the origin of a signed script on the Web, there’s still no reason to trust the creator. If you encounter a script signed by your company’s IT department, you can probably trust it without much risk. However, you’d have no reason to think that a party you don’t know—for example, a random company on the Web—is at all trustworthy. So they signed their JavaScript—that doesn’t mean it doesn’t try to do something malicious! And if it did, most users would have no way of knowing.

In short, most browsers will pop up a scary looking security window asking the user what he or she want to do, and the chances of the user hitting the button marked “no, I don’t dare allow cross-domain XMLHTTPRequest calls” are at least 50-50. And, even if they weren’t, who would tolerate that message appearing regularly?

tags: cross domain, cross domain script exclusion, cross domain scripting, internet security, intranet environment, javascript, javascript security, mozilla, security, security components, signed script, signed scripts, web scripting, web security, xdomain, xmlhttprequest