cross-posted from: https://programming.dev/post/10497245

Hi,

For websites I’ve always restricted username to use Apostrophe ' and " and some times even space . If a website necessitate special character then I prefer to create an additional DB field ~DisplayName.

It’s easier to forbid the use of Apostrophe, otherwise you will have to escape also your search query to match what has been recorded in the DB.

On the topic I’ve this https://security.stackexchange.com/questions/202902/is-single-quote-filtering-nonsense

But if you have better documentation feel free to share :)

Thanks

  • sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    9 months ago

    For a username, your backend should only do simple CRUD:

    • create user
    • read password hash
    • update username (if you support it)
    • delete user

    Other than that, you should be using a backend-generated ID, like a UUID or a login token, elsewhere in your application. So for the backend, your only concern related to secure handling of a username is the proper handling of SQL queries for those operations and encoding over the wire. Wire encoding is well defined (URL-encoding or base64), and SQL injection isn’t a thing if you use a decent library correctly. Don’t try to interpret it anywhere, just pass it along as a bunch of bytes, just like a password.

    So the only thing left is the frontend, where you should be sanitizing all user input anyway. If the frontend wants to sanitize input in some way, ensure the backend has the same check on creates and updates. But that has nothing to do with backend security, it’s merely a convenience to prevent bugs on the frontend.

    • merc@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      9 months ago

      Ok, but that wasn’t the question. The question was “Should you allow username to use Apostrophe (aka quotes )”.

      There’s no mention of what the role of the backend is, just the question of what that policy choice should be. By looking at it only through the lens of the backend, you’re going to cause headaches.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        9 months ago

        We’re in a community focused on cyber security, and the question linked this stack exchange thread, which is explicitly about SQL injection. From that article:

        To block single quotes in all input is madness. This breaks functionality of the application and isn’t even the correct solution against SQL injection.

        The context is SQL injection, which typically is a backend thing. That’s why I talked about BE vs FE. You could instead say “DB layer” vs “presentation layer” if you prefer.

        But my point is that removing single quotes in the context of cyber security completely misses the point. Only remove single quotes (or any other character) if it makes sense for your application use case, not for some vague sense of “security.” If allowing single quotes causes a security vulnerability, your code is wrong even if you disallow single quotes.