My site is like this that user opens it and runs index.php, and in index.php there are many ajax calls to other php scripts in same server directory as index.php. Now im using post, but if user comes to know addresses of these other scripts (like from right-click ---> view page source) then he can run those scripts in their browser, which can lead to inconvenience (e.g sometimes causing blank entries to be inserted in to database, just an example). So how do I disable php execution of those scripts from a browser yet ajax can call them?
-
you should rather check in php if it's blank response and if it is Ajax Response. – Robert Jun 11 '13 at 12:11
-
2You need to validate the input from client. Also its possible to check that the request is ajax or not. – Red Jun 11 '13 at 12:11
-
2If they can be run via ajax, that _is_ through the browser. You can't enable one without the other. If you need to restrict, then you need to make these methods 'safe', validate the input etc. – Grant Thomas Jun 11 '13 at 12:12
-
possible duplicate of [Differentiating Between an AJAX Call / Browser Request](http://stackoverflow.com/questions/216173/differentiating-between-an-ajax-call-browser-request) – Paul Dixon Jun 11 '13 at 12:12
-
@Red Validation should _also_ take place on the server side... the OPs validation won't work if a user is ripping the calls to use in their own script... hence, without the OPs validation! – Grant Thomas Jun 11 '13 at 12:13
3 Answers
You can't, at least not reliably (you can use JavaScript to add extra request headers, for example, but the user can observe those requests and add the headers themselves).
Check that submitted data is sane instead. If a submission to add a blank entry comes, throw an error message back.

- 914,110
- 126
- 1,211
- 1,335
-
1Red > writing your own script to generate an AJAX request isn't very hard, so people could still be running their own requests as AJAX request... – Laurent S. Jun 11 '13 at 12:20
you should check in php script if it is Ajax Reponse
/* AJAX check */
if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
echo 'call from ajax'; //here you have call request by ajax
}
else
{
die("You shouldn't be here");
}
/* not ajax, do more.... *
Most of well known JS libraries use this header. If you don't use library you can set this header by your own.
var req = new XMLHttpRequest();
req.setRequestHeader("HTTP_X_REQUESTED_WITH", "xmlhttprequest");
These headers can be set when attacker tampers data but for common guy who wants to access page via browser it will show "you shouldn't be here" message.

- 19,800
- 5
- 55
- 85
-
This doesn't stop the client using them in exactly the same way as the OP, only they can provide whatever input they like. – Grant Thomas Jun 11 '13 at 12:14
-
`HTTP_X_REQUESTED_WITH` does not mean it is an Ajax request. It just means that someone added an X-Requested-Header to the request. Some JS libraries will do that when wrapping XHR. Not all will, and nothing stops an attacker from adding them manually. – Quentin Jun 11 '13 at 12:14
-
@Quentin Most do. You cannot reliably detect ajax any other way. Not that I know of. – Maxim Kumpan Jun 11 '13 at 12:15
-
1
-
`HTTP_X_REQUESTED_WITH ` is sent by the Ajax functions of most major Frameworks. Now a lot of people use frameworks to handle Ajax Request and this could help OP in his problem. If he uses pure JS he can add this header as well to his script. – Robert Jun 11 '13 at 12:16
Here's what I use to detect AJAX requests:
function isAjax()
{
/* AJAX check */
return (!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest');
}
Please note that this does NOT guarantee detection and can only help stall misguided users, not determined attackers.

- 2,545
- 2
- 19
- 23
-
`HTTP_X_REQUESTED_WITH` does not mean it is an Ajax request. It just means that someone added an X-Requested-Header to the request. Some JS libraries will do that when wrapping XHR. Not all will, and nothing stops an attacker from adding them manually. – Quentin Jun 11 '13 at 12:14
-
@Quentin Most do. You cannot reliably detect ajax any other way. Not that I know of. Anything is better than nothing at all. This helps against misguided users but not dedicated hackers. Never said otherwise. – Maxim Kumpan Jun 11 '13 at 12:16
-
@MaximKumpan Something is better than this: if calls should be _private_ then they should **not** be exposed _publicly_. – Grant Thomas Jun 11 '13 at 12:17
-
@GrantThomas I think that is not even worth mentioning. Even if you can guarantee AJAX detection, nothing stops someone from generating those ajax calls via console. As I said, this helps against misguided users, not attackers. – Maxim Kumpan Jun 11 '13 at 12:19
-
@MaximKumpan What? How can they if the scripts aren't publicly accessible? The way they should be if one is worried about them being used publicly. – Grant Thomas Jun 11 '13 at 12:22
-
@GrantThomas If they're used via AJAX, they are public by definition. You can only stop accidental hits from directly linking to them. – Maxim Kumpan Jun 11 '13 at 12:24
-
@MaximKumpan And you get my point. If they are in danger of being used publicly, and you don't want them to be, then they should _not_ be public in the first place! That is the **only** solution. Don't use AJAX calls to publicly available scripts if you want those scripts to be private. – Grant Thomas Jun 11 '13 at 12:26