Are there any security implications with POSTing a authentication request with the use of javascript/ajax, as opposed to POSTing an HTML element by pressing the submit button?


<form method="POST" action="/login/">
  <input type="hidden" name="csrfToken" value="(...)"/>
  <input type="text" name="username" value="" maxlength="64" autocomplete="off"/>
  <input type="password" name="password" value="" maxlength="1024"/>
  <input type="submit" value="login"/>

example 1: login with HTML-form in pseudo-code


<form method="POST" action="/login/">
    (... same as above ...)
    <input type="button"/> <!-- will trigger javascript method below -->

<script type="text/javascript"/>
    type: "POST",
    url: "/login/",
    data: "(...)", // All form fields
    dataType: "json",
    success: function(data) {

example 2: login with ajax in pseudo-code

This question is only about the javascript/ajax vs html form post, all other things such as TLS, passwords, etc are not my area of interest for this question.

Updated question Added the for field becuase I introduced some confusion by mentioning the csrfToken.

  • Just to note: there should be anti-CSRF token in first variant. In 2nd variant it can be anti-CSRF header or parameter Commented Jul 10, 2012 at 17:47
  • @AndreyBotalov, we do have an anti CSRF token in the HTML-form (the token sparked the question). Can you explain how I would use an anti-CSRF header/parameter?
    – Jacco
    Commented Jul 10, 2012 at 20:24
  • I'm not sure that if you add token to html form in second variant browser will send it. Your code isn't full but browser won't send csrf token if you will bind this button into function with this .ajax. Check it in browser. Commented Jul 10, 2012 at 20:49
  • @AndreyBotalov, the javascript method sends exactly the same fields as the vanilla HTML form.
    – Jacco
    Commented Jul 11, 2012 at 11:19

1 Answer 1


There should be no difference in terms of security, since the POST is handled by the browser in the same way as a form. If you're running HTTPS, it'll go over HTTPS too.

However, keep in mind that complex ajax-based apps are statistically more likely to be vulnerable to XSS than flat HTML pages. This doesn't mean you definitely are, it's just something to watch out for.

Things to consider:

  • Ensure that your script is served via HTTPS. You'd be surprised how many people serve their scripts from a CDN over plaintext HTTP.
  • Proper cross-domain policy should be specified in crossdomain.xml
  • Consider enforcing strict transport security.
  • Configure your Content Security Policy properly.
  • Avoid eval, escape output using contextual escaping, etc.
  • I disagree on the more likely to be vulnerable. IIRC POST and GET request via ajax look EXACTLY the same as regular get/post except jquery (and possibly other libs) add an extra header to state how they are requesting the data.
    – user5575
    Commented Jul 10, 2012 at 13:01
  • 3
    @acidzombie24 I think you misunderstood. I was stating that a vulnerability is statistically more likely because you're introducing more code. jQuery/ajax heavy sites require more executable code than traditional HTML forms, which can comprise entirely of markup. More code means more bugs!
    – Polynomial
    Commented Jul 10, 2012 at 13:03
  • Would an anti CSRF token, as mentnioned by AndreyBotalov, change anything?
    – Jacco
    Commented Jul 10, 2012 at 20:23
  • @Jacko just look at HTTP request sent from browser. If it doesn't have anything preventing CSRF (special token, header ...) then it should exist and be validated at server side. If it has and is validated, then all is good. Commented Jul 11, 2012 at 9:49
  • 2
    @Jacco see my comment above. CSRF token should be in the form. The ajax and non ajax works the same. CSRF token and anything else should be including in either solution.
    – user5575
    Commented Jul 11, 2012 at 11:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .