Yeah, there are plenty of reasons to do what you're doing that seem fair to me. But at the same time, through no fault of yours, your requests are indistinguishable from potentially malicious ones. The whole thing is a mess, effectively a band-aid on top of deeper issues with HTTP's statelessness.
If I'm blocking cookies/referer by default then the onus is upon me to enable them for sites that require them for stuff like this. I wouldn't worry about users who have this issue. Maybe customize django's CSRF failure page to say they need to enable both to use your service and call it a day.
I agree in principle. And I have built a custom CSRF page to help my potential customers out.
In practice, lots of my potential users don't even understand that their AdBlock/whatever extensions are mucking about with Cookies in ways that break things. It's a tough sell to tell someone who is thinking about trying your service: "sorry, I don't work with your browser the way it is" when so much of the rest of the world is either HTTP, not HTTPS, or simply has decided to punt on CSRF or be much more selective about it. It looks to them like _I'm_ the one that's broken.
Humm.. I'm thinking you could write a middleware that checks for Referer over https and if not set, go ahead and set it to https://yourdomain.com That would allow you to continue to use CSRF middleware for the nonce check (just make sure yours is before theirs).
In order to exploit this an attacker would need to be MITM on the network or on a subdomain by setting a wildcard cookie. The site would still keep the nonce check. I don't see any way around this without poking a tiny hole in the CSRF protection. Guess you gotta weigh the cost/benefit.
Also: that's a good link. Thanks.