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:

• "Magic",
• 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%20alternative

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?

Votes: Simon G.