4 ms·

I've found that a key part of CSRF protection is ensuring it gets added everywhere consistently. When new features need to be done yesterday and you have to rev

I've found that a key part of CSRF protection is ensuring it gets added everywhere consistently. When new features need to be done yesterday and you have to review code from 20+ junior developers, it's easy to miss that extra hidden <input> field. That's why I love if it's built into the framework like Django or Phoenix rather than bolted on or home-rolled.

silviogutierrez 6y ago
Big Django user. Isn't it still required that you add the {% csrf_token %} tag to your forms? That is, the protection will be on. But the way to be allowed in by the gate is not on by default. You have to remember to add the tag. Which is why I'm so excited to just switch to SameSite once there's enough browser usage...
- mac-chaffee 6y ago
  My Django is a little rusty but I think now requests will return 403s by default if you forget to include the csrf_token tag: https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-requests https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-req... Whereas the hand-rolled CSRF scheme I've inherited will fail silently
  - silviogutierrez 6y ago
    That's what I mean. If you forget to include the token on your app, it will fail. You have to remember to call {% csrf_token %} in every template. Back in the day, the middleware scanned your response and injected it next to each </form> tag. A hack and dirty for sure, but removed that burden.
    - StavrosK 6y ago
      It will fail securely, which is what you want. The alternative is to have it fail insecurely and bypass validation for everything. In the latest versions the framework sets the SameSite header properly, so you don't need the CSRF middleware at all (you can just remove it).
viraptor 6y ago
What do you mean by built-into? The choice of whether to include a token in a form or not is not always trivial for static analysis tools. On the other hand, if you use some library to handle forms and validation like deform and colander, the CSRF handling is pretty transparent. Also, but validating CSRF on middleware level, you can't forget about it - features relying on POST requests won't work.

silviogutierrez 6y ago

Big Django user. Isn't it still required that you add the {% csrf_token %} tag to your forms? That is, the protection will be on. But the way to be allowed in by the gate is not on by default. You have to remember to add the tag. Which is why I'm so excited to just switch to SameSite once there's enough browser usage...

mac-chaffee 6y ago
My Django is a little rusty but I think now requests will return 403s by default if you forget to include the csrf_token tag: https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-requests https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-req... Whereas the hand-rolled CSRF scheme I've inherited will fail silently
- silviogutierrez 6y ago
  That's what I mean. If you forget to include the token on your app, it will fail. You have to remember to call {% csrf_token %} in every template. Back in the day, the middleware scanned your response and injected it next to each </form> tag. A hack and dirty for sure, but removed that burden.
  - StavrosK 6y ago
    It will fail securely, which is what you want. The alternative is to have it fail insecurely and bypass validation for everything. In the latest versions the framework sets the SameSite header properly, so you don't need the CSRF middleware at all (you can just remove it).

viraptor 6y ago

What do you mean by built-into? The choice of whether to include a token in a form or not is not always trivial for static analysis tools. On the other hand, if you use some library to handle forms and validation like deform and colander, the CSRF handling is pretty transparent. Also, but validating CSRF on middleware level, you can't forget about it - features relying on POST requests won't work.