Changes to make browsable API compatbile with strong CSP by juspence · Pull Request #8784 · encode/django-rest-framework (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation7 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
(Copied from #5740, conflicting CSRF changes removed. These were already handled as part of #7016)
Currently the browsable API contains inline JS for configuring forms and allowing for custom CSRF cookie/header names. Use of CSP with this page requires 'unsafe-inline'.
This patch is a concept for getting rid of all inline scripts from the browsable API. It's not tested, as I just wanted to see if there was interest in merging this before I spend too much time on it.
After testing locally, this fixes the CSP warnings in the developer console, if you have a strict CSP like script-src: 'self' that doesn't allow 'unsafe-inline'.
I came across this pull request as I am currently adding CSP to our Django application. We are using the django rest framework in version 3.14.
With the changes in this PR the load-ajax-form errors are fixed for me.
But the line 290 in base.html is also generating a CSP error.
<script type="application/json" id="drf_csrf">
{
"csrfHeaderName": "{{ csrf_header_name|default:'X-CSRFToken' }}",
"csrfToken": "{% if request %}{{ csrf_token }}{% endif %}"
}
</script>
I think the same approach makes sense in this case and the inline script should be outsourced, as we already have a csrf.js file.
I'm looking forward to your feedback
@mnacken Thank you for reporting! There was an existing PR to fix this issue which I tested (in Chrome and Firefox) then merged:
#7016
Above changed an inline script to use JSON instead of real javascript, which appeared to prevent the script from actually executing. It just made the data / token available in the page HTML.
I'm not sure what browser you're using or why the new form still causes errors, but I'd be happy to look over a PR if you want to submit one. I guess using an external script is also a cleaner, more consistent approach than this dirty hack 😄
Thx for response, you are right!
I made it easy for myself and made the changes manually. With the changes from #7016 its fine!
Is there any roadmap/timeline for releasing version 3.15?
most probably by the end of this month or first half of next month
SpecLad added a commit to SpecLad/cvat that referenced this pull request
I'm looking to add a Content-Security-Policy to API responses, and there
were some important improvements for that in 3.15.0 (e.g.
encode/django-rest-framework#8784).
SpecLad added a commit to SpecLad/cvat that referenced this pull request
I'm looking to add a Content-Security-Policy to API responses, and there
were some important improvements for that in 3.15.0 (e.g.
encode/django-rest-framework#8784).
SpecLad added a commit to cvat-ai/cvat that referenced this pull request
I'm looking to add a Content-Security-Policy to API responses, and
there were some important improvements for that in 3.15.0 (e.g.
encode/django-rest-framework#8784).