GSoC 2023 Proposal Feedback: Bring CORS and CSP to Core

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 -

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

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

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

The link for the proposal is (same as above) - GSoC 2023 Proposal: Bring CORS and CSP Into Core - Google Docs

Thanks for your feedback!


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.

1 Like

Thanks, that makes sense!

Hi @carltongibson, could you please go through the proposal when you have the time and give me some pointers?

1 Like

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… :+1:

Yeah… :grimacing: — I think applying 8 decorators is a bit much…

How would I want to do this…? :thinking: 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 :thinking:)

I would ask @adamchainz if he has a preferred API idea here? :thinking:

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.

@adamchainz would that be in the right direction?

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?

Link to the updated headings - spec, implementation.

1 Like

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?

The above links point to the specific sections, and this is the link to the start of the proposal - GSoC 2023 Proposal: Bring CORS and CSP Into Core - Google Docs

@carltongibson could you give me a final thumbs up if the proposal looks good to submit?


Hi @hrushikeshrv — sorry for the slow reply. Life.

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

Do submit when you’re happy.

Kind Regards,


@carltongibson I understand. Looking forward to submitting!

Hi @carltongibson, I got to know that my proposal didn’t make the cut this year. Hopefully my third time will be the charm!

Was there something missing in the proposal, maybe something I could have done differently? I’d really appreciate your feedback!

Hi @hrushikeshrv

Yes, absolutely! :gift:

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!

Kind Regards,


@carltongibson I understand, looking forward to next year!