I am against adding validation here. See the classic *Falsehoods Programmers Believe About Names*: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ .
Here are some characters that have caused security issues in the past (e.g. URL bar display), but I'd reckon are legitimate in some human names: - non-breaking space - zero-width space - RTL or LTR markers - Quote marks If you do want to block this, we don't need a new argument to Charfield. You can implement a custom validator, and even pair it with a database constraint. But you might block legitimate users. The only change we should be making is moving from separate first_name + last_name fields to solely a name field, since *many* people don't fit into that. I think there's a ticket, but there are massive backwards compatibility concerns. P.S. never forget the case of Mr Null: https://www.wired.com/2015/11/null/ On Tue, 18 Aug 2020 at 09:39, Kacper Szmigiel <[email protected]> wrote: > Hello! > > Maybe some `special_characters` bool field on models.CharField with > default to `False` would do the job? > > > wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers > (Contributions to Django itself) <[email protected]> > napisał(a): > >> Currently, when you order a security audit on a Django project from any >> of the firms I've seen so far (including my own), all inputs fall short on >> stuff like: >> >> "First name input: allows special caracters such as <>/"' which may cause >> a security issue with further developments done on the same database but >> outside Django". >> >> As far as I can imagine, special caracters would be acceptable on inputs >> that should accept code or some kind of math, which is not the case for >> most inputs. >> >> Django should harden default input validation to make it easier for >> Django projects to get a good grade on security audits, without having to >> go over all fields to setup basic input validators. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" 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-developers/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.com >> <https://groups.google.com/d/msgid/django-developers/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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-developers/CAFfZ%2Bb4GNSksSUm%3De8bQAp1t1qgDkLvNpitYjLmY1QHb94vs7w%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFfZ%2Bb4GNSksSUm%3De8bQAp1t1qgDkLvNpitYjLmY1QHb94vs7w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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-developers/CAMyDDM2CsjYg-8DJ2AyOpbbnn-vR-CUK9DSSf-1_wywJejg4aQ%40mail.gmail.com.
