On the project I'm working on, I noticed that on login there is a check in backend which checks if the request is an ajax reques (checks 'X-Requested-With: XMLHttpRequest') or not. If the request is an ajax request the login is performed, otherwise the request if deniend.

Nobody knows why this check is needed here and the people who added this checks are not available. This rise some questions in my head, why a REST service should not be allowed to login using a 'non ajax' request? it is more secure (I don't see how)?

The only benfit on backend side I can see for this is if we want to server diferent content (html for 'non ajax' requests, json for ajax).

Are there other advantages/disadvantages to use this check?

  • 1
    It's difficult to know why that's there without knowing more about your system from the original people. If I were to guess, I'd say that the system was originally built specifically for ajax, and disallowing non-ajax requests is a simple check to shut out any other type of request that the service is not going to process anyway. Commented Apr 2, 2018 at 16:33
  • stackoverflow.com/questions/17478731/…
    – Ewan
    Commented Apr 2, 2018 at 16:35
  • That would have been my guess as well: standard practice by the devs rather than any specific reason for the login. Are these types of checks present elsewhere also?
    – jleach
    Commented Apr 2, 2018 at 16:36
  • This check is present only on login endpoint.
    – haraki
    Commented Apr 2, 2018 at 17:02
  • 1
    This was probably intended as a weak attempt to block simplistic bots from testing out user/password combinations. I'd get rid of this check since it is easily circumvented, and suggest rate limits and monitoring instead.
    – amon
    Commented Apr 2, 2018 at 17:18

1 Answer 1


To serve different content, proper content negotiation should be used. Base content type on some custom header instead of Accept request header makes things more complex than they need to be. However, you're right that this could be one of the reasons, implemented by a person who was unfamiliar with HTTP.

Another possibility would be to make the system more secure. Although this is a wrong way to secure the system (since the restriction can easily be circumvented by the client adding the requested header), it prevents “simplistic bots from testing out user/password combinations,” as stated by amon.

A third possibility would be to make sure login requests are always done through AJAX (for some cryptic reasons). This way, if the client-side code is changed to do ordinary POST to login, it will be quickly possible to figure out that something went wrong, since the login won't work any longer.

None of those reasons is strong enough to justify the use of the custom header:

  • Content negotiation should be done using standard HTTP mechanism. There is no need to reinvent the wheel just to make the maintenance more difficult than it needs to be.

  • Security should be handled properly, using standard security procedures. The subject is ways too large to be described in an answer, so see Security.SE and the books on the subject, if interested.

  • If there is a valid reason to make only AJAX logins, the code should be changed to make this reason very explicit. If there are no reasons, it should allow both AJAX and non-AJAX login actions to make it possible to use the website by people who disabled JavaScript. Depending on the application, this may not make too much sense (if the remaining application relies fully on JavaScript, there is no reason to let such users in anyway).

  • I came here to answer this question, but fully concur with the advice here—well done Arseni. I would only add that, where authentication is required, do not use Cookies but the Authorization header instead, for both HTML and JSON. Commented Apr 4, 2018 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.