GSOC 2023 Discussion on Security: Bring CORS and CSP into core.

Hi everyone, I want to contribute to this project as a part of GSOC 2023 due to my experience with some of the PRs related to HTTP handling and my own research on requests and Django security, I’ve created this discussion to get some more details about the project and get going in the right direction!
I went through the discussions from mailing list and also various tickets where I noticed some key points and they are as follows:

  • Firstly, according to @adamchainz django-cors-headers implementation is a bit janky, for example it uses a regex to filter paths. It also lacks the key ability to set up different CORS policies per path so both of these could be done with a decorator.
  • Second, according to @ubernostrum the current django-csp third-party app isn’t necessarily bad, but he’d love to see more good security tools in Django by default.
  • Paul Mcmillan in this comment also approves of adding django-csp to Django core.
  • According to the closing notes from Tim Graham on CSP it should be added to the SecurityMiddleware, and according to me adding CSP and CORS to SecurityMiddleware would be a better approch rather than making seperate middlewares.
  • Making the admin compatible with CSP is something to look out for also making a standardized way of dealing with nounce and hash sources as stated in a comment from Gavin Wahl. As the inline JavaScript from the admin is removed in Ticket #25165 so we can now add CSP headers in core as stated in the comment from @timgraham .
  • We’ll also have to have support for Report-Only/multiple polices for debugging and stuff.
    CSP needs to add support for users can set their custom policies for admin page.
    The benefit of adding CORS and CSP is obviously added security by preventing XSS.
  • Why bring them to Django core and not use at other layers such as ngnix?
    • depends on your application.
    • can do layering of policies like make strict policy on higher levels and customize it at lower levels in applications for different views.

@carltongibson could you have a look over this and tell if I missed something it would be great if you could. :smile:

Hi @Anv3sh — It looks like you’ve summarised the state of play so far :+1:.

I guess digging into the implementations and making sure you’re clear on exactly what’s involved would be the next step forward.

1 Like

Thank you for the feedback @carltongibson I’ve been thinking about the implementation and have some ideas in my mind, will post it after some refinement.

Also we need to note that #25706 (Support CSP default-src ‘self’ on Django Admin GIS) is still open and a non-trivial issue as stated by @claudep in this comment.

@carltongibson @adamchainz I created a draft proposal GSOC Proposal [Security: Bring CORS and CSP into core] - Google Docs I would be glad if you could review it once :smile: .
Some key notes on the proposal:

  1. CSP is to be added to SecurityMiddleware as suggested by @timgraham in his closing notes on PR-5776. I will be following the design of Referrer Policy and implementing some extra features such as nonce context processor.
  2. A doubt that I had is since CSP consists of a number of directives so will creating settings attributes for each one of them be a valid option or we can stick to the proposed way of declaring it in a single comma separated string as done with Referrer Policy.
  3. Currently this proposal proposes CORS to be implemented via the addition of CORSMiddleware but I was thinking if implementing CORS into SecurityMiddleware would be the right way or not?
  4. Also since I propose to add CSP to SecurityMiddleware we would have to create SecurityMiddleware._make_nonce(request), I don’t know if this breaks the design of SecurityMiddleware. The mock implementation of CSP in SecurityMiddleware can be seen here CSP mock implementation .
  5. Decorators will be added to both CORS and CSP with CORS having 3 decorators and CSP having 4 decorators.

HI @Anv3sh — the proposal looks OK at a high-level. Likely there’s some discussion to be had over the exact API design… (seems like a lot of decorators… but maybe it’s the cleanest way… — I’d ask e.g. @adamchainz to opine on the actual project.)

This is a good point to catch Did you have anything to say about it?

Kind Regards,


@carltongibson I haven’t worked with GeoDjango yet but as mentioned by @claudep and as I discovered myself there exists inline scripts in contrib/gis/templates/gis/openlayers.html (extending to openlayers-osm.html) which will have to be migrated somehow.

OK, great. Do submit! Thanks.

Hey @carltongibson I got to know my proposal couldn’t get accepted this year could you please share the shortcomings or the reasons it wasn’t selected maybe I could figure them out and try next year :blush:.

Hi @Anv3sh — I think we may have been short on slots, and there were perhaps richer proposals submitted. For personal reasons I wasn’t involved in the final decision, so I can’t say more.

Do stick with us, and good luck next year!

Kind Regards,


1 Like

Thanks for the feedback, Carlton. Looking forward to try next year again :smile: