I'm working on a project that requires to have a signup/login functionality exposed to partners who manage their own website. For some of these websites they reuse our own backend, and just change the css styling, but other are completely standalone: for this reason it has been thought to prepare a static login form that would be given to the partners, which would trigger a POST request to our own servers.

(depending on the arguments in the form, we would keep track of which partner brought us which users, which apparently covers a business need for analytics)

We're currently missing CSRF protection on some endpoints, like the login one. When asked to look into it, I realized that with a static form, we'd be unable to add CSRF tokens.

It seems to be a minor issue, but it'd be nice to protect our users from login CSRF. For this reason I thought of 2 alternatives:

  • add a confirmation step before logging in the user when a conflict is found in the session cookie (ruled out due to the changes in the logic flow for session management being too invasive)
  • instead of a static form, let our partners use an iframe which will contain our own login form, with CSRF protection and all. This would require relaxing the X-FRAME-OPTIONS specifically for the page that will display this login form

Is there a better solution? I don't think that clickjacking on our login form should really be a concern (and clickjacking is normally used to do what could otherwise be trivially obtained with a CSRF, I reckon... so fixing the latter seems to have an higher priority)

  • 1
    Why do you need CSRF protection for a login form? Mar 24, 2016 at 9:53
  • 1
    It's a login CSRF: definitely not a serious vulnerability by itself, but it's still worthwhile to prevent abuse. The same thing has been found and fixed on HackerNews 1 month ago: news.ycombinator.com/item?id=11177673 and in a commercial site in which the user can actually purchase goods/services the issue is obviously slightly more important than on HN
    – berdario
    Mar 24, 2016 at 11:25
  • Not sure I follow. Is the "static login form" a part of the 3rd partys website?
    – Anders
    Mar 24, 2016 at 12:05
  • sort of, yes: we created the form, and then this would be included by our partner on their site (where they'd handle styling, css...)
    – berdario
    Mar 24, 2016 at 12:31
  • Might be worth considering SAML so you run an IdP and clients are an SP. The IdP could use different styling/template for different SPs.
    – Phil Lello
    Mar 24, 2016 at 19:55

3 Answers 3


You could check the Referrer header. This is often recommended against when there are better alternatives, but as far as I know it's not a particularly bad technique and only recommended against because some users strip the header for privacy reasons, and historically some popular browser plugins had vulnerabilities that allowed the Referrer header to be manipulated.

(I think iframes are the best solution here if you can use them. Click-jacking against a login form doesn't seem like a realistic worry. Second-best solution, using some javascript to do an AJAX request against your domain per berdario's solution maybe with a Referrer-header-check fallback for browsers that don't support cross-origin requests.)


I realized that there's another possible solution:

Create an endpoint that will return a CSRF token, return a Access-Control-Allow-Origin header that will grant access exclusively to our partners' domains, and add some javascript that will fetch this token and modify the (otherwise static) form by adding it as an hidden field.

This would remove the need to use iframes, but I think that security-wise is an inferior solution: the more partner domains will be added, the bigger the risk that one day one of these will disappear, we will forget to remove it from the header and the domain name will be squatted... potentially exposing ALL our endpoints to CSRF attacks again. (compared to the insignificant clickjacking risk on the login form only).


I think you need to implement one of the best practices for login, limit the number of login attempts (for instance, 5 attempts), after that you should block the account for some minutes (for instance, 30 minutes). I think it is a good solution, because you can control the automation attempts (bruce force attack) in a easy way.

  • 1
    I don't think this would help against a targeted attack against one of our users, but it's definitely something that we should do regardless. Thank you for reminding
    – berdario
    Mar 25, 2016 at 14:39
  • If an attacker was trying to get victims to log into the attacker's own account that they knew the password to, then there wouldn't be any failed attempts. Login rate-limiting doesn't address the attack at all.
    – Macil
    Mar 25, 2016 at 22:26

You must log in to answer this question.

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