Ajax Backend Scripts with PHP (5 pieces of advice)

#1. Remember to authenticate AJAX requests.

From the web server point of view, an AJAX request is no different from a standard HTTP request.

You can write a PHP script that works as an AJAX backend. But if a remote user sends a standard HTTP request directly to that PHP script, the script cannot tell the difference from a real AJAX request.

For this reason, it's important that you consider authentication when returning data or executing operations in an AJAX backend script.

If the script returns private data, you need to be sure that the request is coming from an authenticated session.
And if the script executes a command, you need to make sure that the request is legit.

There are two ways to do that:

Use Sessions.
AJAX requests usually send the Session cookie even if they are sent from JavaScript. Therefore, you can check the PHP Session to check whether the remote browser is authenticated.
Use a security token.
If you cannot use Sessions, you can add a security token when generating the JavaScript page, and make the AJAX request send the token back so you can check it.

Whatever your choice, never trust AJAX requests blindly.

#2. Validate the request parameters.

Just like you cannot trust the authentication status of an AJAX request, you also cannot trust its request parameters.
Your script may expect specific parameters (those found in $_GET and $_POST) from the AJAX request. However, you cannot assume that those parameters are always sent, or that they are correct.

Indeed, many hackers target AJAX backend scripts because these scripts often lack proper input validation.
Such attacks are even more dangerous when database queries are executed, because they can lead to SQL injections.

You must validate input values from AJAX requests exactly like input parameters from standard HTTP requests.
You must validate them and make sure their values are correct.

#3. Reduce the AJAX scripts overhead.

AJAX backend scripts usually need to perform simple operations, like returning some data to the front-end app.
Therefore, these scripts do not usually need all the functions and classes that other scripts require.

You can limit the amount of code included in AJAX back-end scripts to make them faster and less resource-hungry.
This is especially important for those scripts that are called often (some AJAX requests are executed every few seconds).

A good idea is to create a dedicated "AJAX include" script with only the necessary functions and classes.

#4. Choose the right reply data format.

AJAX request replies can use different data formats, the most commonly used being JSON, XML, CSV and pure front-end code (such as HTML).
If you can choose which format to use, take your time to choose the most appropriate for your case.
Here are some guidelines:

JSON is a readable and flexible format with a relatively low overhead. It's today's most popular format thanks to its easy syntax, and it should be your first choice.
PHP can handle JSON data easily (you can find my tutorial here).
Note that JSON can become problematic when dealing with nested data.
XML is not very used today, because of its hard-to-read syntax and its data overhead.
Still, XML is a good choice if you have complex data organized in many nested levels.
CSV is a very simple format that basically resembles a table: you have rows, and each row has columns.
CSV is a good choice for very simple replies. It has very low data overhead and it's very easy to read.
Finally, you can pass front-end code such as HTML directly. This is usually done when the JavaScript code must insert the code dynamically into the page.
Be sure to encode the data into a safe format such as Base64 before sending it, or some characters could break the request.

#5. Include a status return value in the reply.

It is a good idea to always include a "status" value when sending an AJAX reply.
This value tells the JavaScript app if the backend has processed the request successfully, or if some problem occurred.

You can use a different status value for each situation that may occur, such as:

The request has been processed successfully.
The user is not authenticated.
The request parameters are not correct.
An internal error has occurred (such as a database query error).

The JavaScript app can then display the proper message to the user.