#31287: Rename mark_safe and "safe" template filters to something less safe
sounding
-------------------------------------------------+------------------------
Reporter: Adam (Chainz) Johnson | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Template system | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------------------+------------------------
As discussed on django-developers in Jan 2018:
https://groups.google.com/forum/#!msg/django-developers/AvgxWR-0VrE
/b8a3g8q-AwAJ . And occasionally brought up again in other community
forums, many developers reporting overuse of `mark_safe()` in real world
projects.
Copying Stuart Cox's first post from the mailing list thread:
> In my experience, misuse of `mark_safe()` — i.e. marking stuff safe
which isn’t actually safe (e.g. HTML from a rich text input) — is one of
the biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs have
just got too used to `mark_safe()` being the way to insert HTML in a
template. And it’s easy for something that was safe when it was authored
(e.g. calling mark_safe() on a hard-coded string) to be copied /
repurposed / adapted into a case which is no longer be safe (e.g. that
string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that
there are dangers around similar features, and that this isn’t something
you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>
> Relatedly, this topic suggested making it more explicit that mark_safe()
refers to being safe for use in HTML contexts (rather than JS, CSS, SQL,
etc).
>
> Combining the two, it would be great if Django could rename mark_safe()
to dangerously_trust_html(), |safe to |dangerously_trust_html,
@csrf_exempt to @dangerously_csrf_exempt, etc.
>
> Developers who know what they’re doing with these could then be
encouraged to create suitable wrappers which handle their use case safely
internally — e.g.:
>
> {{{
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
> }}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31287>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/053.5e06e12d9b11494ffbfec82d32c5ff9f%40djangoproject.com.
