When I proposed the lead developer of an open source web application to enable JSONP for the API, the developer replied:
The whole thing sounds easy enough to implement, but I have some doubts that it will open the project to XSS attack of some sort. Don’t really know why, though. 🙂
We mailed a bit more about the risks of cross site scripting and then he wrote the following:
Sadly we can have malicious JS problems since cleaning up of incoming data is optional.
For an unrelated project I asked about authentication for a write-operation in the API and the reply was:
Authentication is not in the API yet. Currently you must include a session cookie along with API requests to perform a write, but the cookie itself is the one you get from logging in [in the web front end] as you would normally.
Which sounds a lot like “we support cross site request forgery out of the box” …
As with normal web applications, web API-security is an important (but complex) issue, which is not always easy to grasp. Based on a basic understanding of things, the following guidelines can go a long way into securing things both on the API-side and the client:
- Know who you’re dealing with; disable API-access for your users by default (allowing them to opt-in), provide bullet-proof authentication and session management in the API and throw in a synchronizer token to prevent cross site request forgery
If you apply these basic principles to JSONP (make sure to filter the callback-parameter and set the correct content-type in your response) you’ll have a whole lot less to worry about!
- Owasp top 10 Application Security Risks 2010 (released on April 19th)
- Owasp Ajax security guidelines
- HTML Purifier: HTML filter library written in PHP.
- The risk of XSS and CSRF with JSONP (auto-translated from Swedish)