A couple of months ago, I received a request from a random Internet user to add CSRF protection to my little web framework Microdot, and I thought it was a fantastic idea.
When I set off to do this work in early November I expected I was going to have to deal with anti-CSRF tokens, double-submit cookies and hidden form fields, pretty much the traditional elements that we have used to build a defense against CSRF for years. And I did start along this tedious route. But then I bumped into a new way some people are dealing with CSRF attacks that is way simpler, which I describe below.
Implementing a security feature
An often shared piece of advice is that you should never implement security features yourself. Instead, you should look for well established solutions built by people who think about security day in and day out.
Unfortunately, as the lead (and only) maintainer of Microdot, I do not have an ecosystem of existing solutions available to me. Even though I gladly accept external contributions, most of the framework has been built by myself out of nothing. So in this case, like many other times before, I felt I had no choice but to go against the standard advice and write CSRF protection code by myself, because if I didn't do it then the feature would not be built.
What is the first step when you need to build a security feature? Check out what OWASP has to say about the matter.
So, in early November, I opened OWASP's CSRF Prevention Cheat Sheet page to see what was new and interesting in the world of CSRF protection. And I found that nothing of significance had changed.
According to OWASP, the best CSRF protection you could get (at the time I checked) was still built around the idea of using anti-CSRF tokens. So I set off to implement this for Microdot.
A disturbance in the (CSRF) force
I was happily making progress on my CSRF implementation, and then in early December, another random Internet user dropped an issue on the Flask repository, proposing that Flask adds support for "modern" CSRF protection. Modern? How could there be a new way to protect against CSRF that isn't mentioned by OWASP?
... continue reading