People often think that because they're using Ajax requests regular sessions don't work. They do. If you have an endpoint to delete something from the database that's visible in the source code, such as:

example.com/user/1/delete

You can protect this request from non authenticated users the same way you would when using a non Ajax HTTP request in the browser. Using sessions. If the user has the privileges to remove users, this route will work, otherwise return an error (or do nothing).

You can also protect an API using OAuth. There's a great document here that explains how it works: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/

Most of the answers are not helpful if you have your app and your api on separate domains for example app.example.com and api.example.com - in that case sessions won't work and you would have to turn to OAuth which is quite a big hammer for such a simple problem.

Here is what I would do:

I assume you have users in a database and a unique identifier like user_id=12345. I also assume that you have your Jobs in a Database and they also have unique ID's like job_id=6789.

First on app.example.com you encrypt both IDs with something fast and easy like Blowfish:

$secret_uid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($user_id));
$secret_jid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($job_id));

I assume your endpoint would work somewhat like this:

api.example.com/jobs/delete/<job_id>/<user_id>

so now from Ajax you call that endpoint, but instead of calling with plain IDs

api.example.com/jobs/delete/6789/12345

you call it with the encrypted IDs:

api.example.com/jobs/delete/6A73D5B557C622B3/57F064C07F83644F

On the API side of your software you decrypt the parameters:

$jid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_1>);
$uid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_2>);

Now you can search your db for uid and jid and perform whichever task you were planning to do. Make sure that a user can only delete his own jobs of course.

I admit this is not a 100% solution, but it leaves an attacker with a lot of guess work - he would have to guess the user_id and a matching job_id, the encryption algo and your secret. It does not protect against running millions of brute force attempts to guess a matching pair, but it put's the odds in your favor (and you should have some sort of quota limitation protection of your endpoints anyway).

Good luck!

There isn't one. If you give someone some data, then they can process it in whatever way they like. You can't control what happens to it after it leaves your server.

Likewise, you can't control what data they send to the endpoint.