Anytime you add editing capability to the page, you run the risk of opening your application to unwanted access. However, with most applications, the framework is such that you can protect the in-place editing as much as you can any other editing. The only thing you can't do is to protect the page itself. At least, not if you're adding in-place editing to a page that other people can access.
Example 6-3 used WordPress cookies, and the in-place editing is going to be as secure as WordPress editing is generally. That's good. Now, where it can be especially vulnerable is in the edit processing. The fact that we're using a
POST helps, but we could add another level of security by again testing the validity of the user making the edit before saving it. Though not featured in the application, you'll also want to check to ensure that no SQL has been appended to the data, to prevent any form of SQL injection hack.
Most of an application's vulnerabilities exist regardless of whether you're using Ajax or not. However, as you use Ajax, such vulnerabilities may become more apparent. One is the SQL injection.
An SQL injection occurs when nefarious users attach a bit of SQL at the end of the text or in place of the text within a form input field. However, as you begin to incorporate Ajax more and more into the application, such vulnerabilities may become more acute. One such vulnerability is known as SQL injections. ...