CSRF compatibility with Flask-WTF

[jace]

WTForms (as of 1.x) and Flask-WTF have in-built CSRF protection. Is Flask-SeaSurf compatible with these, or should I disable one of them on views that handle WTForms? Will appreciate this being covered in the documentation.

[maxcountryman]

You should disable CSRF protection in whatever form framework you're using. While it's possible to use both, I'd strongly recommend against it. It's possible in the future we may have the option to disable all views by default and then opt in select views, in that case you could keep it enabled for whatever form framework you'd like and then selectively apply SeaSurf where needed.

[asmith26]

@maxcountryman Is there any benefit in using Flask-SeaSurf over Flask-WTF for handling CSRF protection? As far as I can tell, only forms ever appear to POST(?). Thanks!

[nk9]

It would be helpful if this question were answered in the documentation. It's clear that one CAN use SeaSurf instead of WTForms built-in CSRF token. But it's not explained why one would choose a separate library over using the one built into WTForms.

I expect the answer is that SeaSurf can be used outside the context of a form, for example if you are sending AJAX/XHR requests to the server to fetch data. In this case, you would need another way to generate and manage the CSRF token(s) which isn't directly linked to the forms library. (The implication being: if you only use forms to POST/PUT/DELETE data, then it's fine to stick with your form library's built-in solution.) [Edit: You can in fact use the WTForms extension CSRFProtect to generate CSRF tokens for non-form tasks.] But perhaps there are caveats that aren't immediately apparent. Seeing this spelled out in the docs would be helpful for those who are new to protecting against CSRF attacks and just want to find the best practice solution with a minimum of confusion.