Hi all, I’ve started this discussion to get feedback for my proposal for the project - Security: Bring CORS and CSP Into Core. This is a first draft of the proposal, so please do let me know if there are some points to be clarified or added to the draft, or if it could be improved in any way.
I want to bring up some points for discussion -
I’ve proposed CORS decorators to be added, one for each CORS header. This leads to the addition of 8 new CORS decorators, which might become too granular. Would one decorator per CORS header be helpful, or should they be combined into a couple of decorators for setting all CORS headers at the same time?
django-cors-headers lets users send CORS headers to a few specific urlpatterns by specifying a regex. CORS headers are only sent to requests to urlpatterns that match that regex. I think that that would be a good feature to have, but at the same time performing a regex match for each request would not be ideal. I’m not sure how we could provide this functionality without using regexes, however.
As mentioned in the documentation for django-cors-headers, the referrer checking performed by CSRF on secure requests could conflict with CORS. I’ve tried to search for information online, but I don’t completely understand where CSRF referrer checking and CORS can conflict. Why does CORS require referrer checking to be exempted?
Regarding your third point, the documentation isn’t saying that there’s a conflict. It’s saying that CORS and CSRF are different, and that making a site trusted from a CORS perspective (which sets response headers that communicate to the browser) is different from making it trusted from a CSRF perspective (which allows the server to execute unsafe requests). That is: adding a site to CORS_ALLOWED_ORIGINS does not mean that Django will actually execute unsafe requests from that origin; to do that you also need to add it to CSRF_TRUSTED_ORIGINS.
Hi @hrushikeshrv — thanks for the ping — this had fallen off my radar with the activity this week.
The proposal looks good in overview. I need to read it more closely but…
Yeah… — I think applying 8 decorators is a bit much…
How would I want to do this…? I think I’d want site defaults in a single setting, plus a single decorator, maybe taking kwargs, that I’d wrap round a view in the URLConf. (Again )
I would ask @adamchainz if he has a preferred API idea here?
Thanks @carltongibson.
Yeah, I felt that one decorator per header would be unnecessarily granular, but thought I would ask anyway…
A single decorator taking kwargs sounds good, that would allow per-view customization. And maybe we could have another decorator that would take some sort of callback function, and would allow per-request customization of the CORS policy? django-cors-headers implements per-request customization by providing a signal, but I feel a decorator would provide a better experience.
Hi @carltongibson, I’ve updated the proposed CORS decorators to now include 3 decorators. I think the new decorators make the proposed spec much simpler and consistent with what I have proposed for the CSP decorators as well. Could you take a look and see if they seem okay?
I have polished the proposal a little bit, and I think it’s close to being ready to submit. One thing I would like to ask is about the CORS decorators and CSP decorators I have proposed. @adamchainz could I please get your opinion on the proposed API?
I think the proposal looks good. It’s not necessary that we 100% commit to one API or another at this stage — we can decide finally during work. (But it seems reasonable, yes.)
In the end, there was just another proposal (several, but one that mattered) that was better developed.
For personal reasons, I wasn’t involved in the final decision, so I can’t say more.
Please do stick with us — you’re list on contributions is already looking good, if I’m reading your CV say — and do apply again next year!
— I think applying 8 decorators is a bit much…
I think I’d want site defaults in a single setting, plus a single decorator, maybe taking 