Protecting your AJAX pages from non-AJAX requests

April 25, 2009

While combing some forums, I came across a rather common problem that had honestly never even considered until now: How do you set up a page that is called via AJAX so that it can properly handle non-AJAX requests? For example, if a page makes an AJAX call to a page called ‘get-products.php’ how should someone just typing in ‘get-products.php’ in their browser be handled?

The solution is to look for a server variable called HTTP_X_REQUESTED_WITH

When a page is called via an AJAX request, the value of this should be set to “XMLHttpRequest” but if the page is simply called manually through the browser, this variable will not even be in the server variable collection.


7 Responses to “Protecting your AJAX pages from non-AJAX requests”

  1. This is a great tip; I’ve always wondered that. I’ve been sticking to tacking on a &ajax=1 parameter onto the query variables, but that obviously can be called directly if someone figures it out. Any ideas on what browsers/versions support this technique? All of them? Thanks for the nice digging.

  2. Robert van der Linde said

    The problem with relying on http headers is that you can never be sure if they are correct. For example, some proxies (widely used in the corporate environment) will block these headers, which breaks your functionality.

  3. Like Robert, I’ll point out that not only could the header be missing, it could be added quite easily as well. This will work in general, but is not foolproof.

  4. Vincent said

    Yes! Can not rely on HTTP HEADER since overwriting them is quite easy! But we must deal with this! Because the other way is passing some GET or POST varible to create a flag for Ajax request! But overwriting GET 0r POST parametere is even much easier than overwriting HTTP HEADER!
    Or we can combine two way! lol
    At least, this tip is very useful!

  5. dan said

    Cookies/sessions is the way to go on this one in my opinion.

    Cookies seems to be less resource hogging method.

    Obviously, it’s up to you what’s inside the cookie (MD5 of the user name, etc).

  6. tixrus said

    Yes although this is cool I wouldn’t trust it 100%. It would depend on what the ajax called script did. If it just fetched some color or something this protection would be fine against the casual poker. But if the ajax script burrows deep into the white and vulnerable underbelly of your database I’d make the caller authenticate to it some other way.

  7. jaywink said

    I’ve used sessions in mine. It’s secure and works great.

    I suppose some sort of code generated with JS with some sort of algorithm would work as well, but then if someone really wants to use your function they will dig it out of the JS code.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: