[abeld]

How exactly?

Due to django's "we want the templating system be general, to be usable for stuff other than html", it can't provide support for such 'guarantee that the output is well formed / valid / has no injection attack entry points' features.

[AndyKelley]

> How exactly?

Everything is escaped by default, and you have to explicitly request for your content to be unescaped.

[wisty]

OK, you escape stuff. Great.

How do you handle user-submitted image tags? Do you allow rich formatting, and if so, how do you sanitize it? (see http://www.codinghorror.com/blog/2008/08/protecting-your-coo...)

I think that Django uses sha for password hashes. They should use bcrypt, right? Did you turn on XSRF protection (which I think is off by default)? Are cookies secure?

Web security is not as simple as 's.replace("<","&lt;")' (escaping by default).

How do you generate slugs? Could someone put something nasty in a pathname or URL?

Django is not secure. You can secure it, with minimal effort, if you keep things radically simple. But you do need to know what can go wrong, so you don't introduce any "features" that are actually "gaping security holes".

Even if you do everything right, it doesn't mean that Django is magically secure no matter what people use if for (obvious, yes, but this is HN and sometimes failing to point out the obvious can get you downvoted). That's why people are objecting.

[Pewpewarrows]

Handling user-submitted image tags is (in my opinion) way outside the scope of the framework. Which tags and attributes to whitelist, or whether to use html markup at all compared to a different language like markdown, is very project dependent. If you have to, just install BeautifulSoup or any of the other great libraries that have cropped up in the last year or so to handle the sanitizing.

Django uses sha for password hashes because until recently there hasn't been a better library to ship with natively across all the platforms that Django supports. If you know you'll only be working on *nix, django-bcrypt can enhance the default password hashing behavior. As other commenters have noted, they're moving to PBKDF2 in the near future as a better included hashing library.

CSRF is on by default. If you need secure cookies and HSTS headers, there's a package that provides them called django-secure, which last I heard is being rolled into Django proper in the near future.

Django prevents path traversal and anything else you can imagine that might be nasty in a URL. The auto slug generation included.

So how exactly is Django not scure again? Where are the "gaping security holes"? Or do you have no idea what you're talking about.

[jwpeddle]

CSRF in on by default. Cookies could be more secure, and it's being worked on. Django is moving to PBKDF2 (there's no pure python bcrypt lib). There's not really opportunity to do anything interesting with slugs.

Like any framework, there will always be room to improve security, but it does do very well out of the box. At least it makes you work to expose anything obvious.