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