The more I think about it, the more I find I have two objections to the auto-escaping stuff.
1. A philosophical objection. One thing Django does, and does pretty well IMHO, is encourage best practices. Pretty much every aspect of Django, from the overall architecture of the framework to the workings of individual bits, involves some sort of explicit "this is a good way to do things"; whether it's the loose coupling of the major components or little things like encouraging the use of HttpResponseRedirect after a POST, we do our best not to magically enforce these practices, but to explain why they _are_ best practices and why you should take advantage of our support for them. The result is that people both use _and_ understand these best practices, which makes them better developers and leads them to build better apps. Any form of automatically-enabled escaping would be a serious break with this, and would move us out of the realm of "this is a good way to do it" into "this is what we say is the right way to do it, and we're going to try to make you do it this way". I don't like that. 2. A security objection. Escaping content on output is only half the battle; there's no such thing as a truly secure web application, and escaping content on output glosses that over by pretending that a magic incantation will solve XSS problems. The best practice for securing against XSS also involves, at the very least, doing input sanitization as well -- relying on output escaping alone both concedes that malicious users can get what they want into your database, and creates a single point of failure. If there's a bug in the escaping system, or if someone forgets to use the correct escaping commands, then the unsafe data that was stored can be sent down the wire to wreak havoc. If input sanitization is in use as well, that's one more layer of protection that can keep unsafe data from ever getting to the DB. So, here's a proposal: Let's implement the escaping system -- off by default -- and play up that any time you're outputting something which came from a non-trusted source you should escape it. Some people will likely continue to rely on selective application of the existing 'escape' filter, but there are bound to be situations where a block tag is a better solution so the flexibility of having both will be good. And while we're at it, let's get serious about input handling. The first thing which occurs to me is to add a 'hasNoHTML' validator in django.core.validators; possibly this would be accompanied by a boolean 'allows_html' argument to TextFields and CharFields, or maybe we just advertise judicious use of validator_list. Either way, the documentation should emphasize as strongly as possible that it exists and should be used. And above and beyond that, I think we really need a well-written security best-practices document which would cover escaping and input validation as well as other factors. There are plenty of things within Django that can be done to enhance security, and there are plenty of non-Django things that users can implement to supplement that (e.g., if you're using Apache, get mod_security). It'd be great to mention those and provide some concrete examples of how to use them effectively. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
