Auto-Escaping Proposals

This is a list of the various Autoescaping proposals to protect against Cross-Site Scripting. See AutoEscaping, django-dev for discussion.

If you want to vote for one of these alternatives, please choose the one that you would prefer and place your name after the Votes part.

1: Nothing

Let the developer deal with it.

Pros:

  • Backwards Compatible
  • "Pure",
  • Already implemented. yay!

Cons:

  • Prone to XSS,

Votes:

2: A context Autoescape Toggle

"adding a new property to the Context class, called autoescape. This defaults to being set to True, but can be toggled either in view functions or by {% autoescape off %} blocks in templates. The VariableNode render() method then uses this context flag to decide if escaping should be performed or not". See AutoEscaping

Pros:

  • Safe
  • Easy for template author to toggle.

Cons:

  • will require some way of marking strings in Django as "escaped"
  • will need lots of rewriting of existing templates
  • Backwards Incompatible

Votes:

3: Add a "finalfilter"

Provide a {% finalfilter %} block tag to automatically add filters (for html escaping, |escape) to any variable tag defined within the block. See AutoEscape alternative

Pros:

  • Safe
  • Easy for template author to use.
  • Backwards Compatible
  • Allows use of other escapers as a finalfilter so not just HTML

Cons:

  • What would be the default status?
    • Not sure I understand the question. There's no "default", you have to turn it on yourself and specify the filter. --SmileyChris
  • Doesn't protect template tags ({% tag %} tags)

Votes: Simon G.

Last modified 17 years ago Last modified on Apr 18, 2007, 3:40:50 AM
Note: See TracWiki for help on using the wiki.
Back to Top