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.
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?