CSRF Protection without Tokens or Hidden Form Fields
blog.miguelgrinberg.com
A couple of months ago, I received a request from a random Internet user to add CSRF protection to my little web framework Microdot, and I thought it was a fantastic idea.When I set off to do this…
  • Consti@lemmy.worldEnglish
    1·
    2 hours ago

    The value of this header cannot be set via JavaScript, so the server can assume that a) if this header is present, then the client is a web browser, and b) the value of the header can be trusted.

    This is already obviously wrong. It cannot be set from JavaScript, true, but any other client including scrapers may set it. So (a) is completely untrue, it being present implies nothing and (b) is also untrue by the nature of networking. You can only assume that it either came from a browser without manipulation, in which case the value can be trusted, or from an external source, in which case the attacker may set an arbitrary value.

    • JakenVeina@midwest.socialEnglish
      1·
      51 minutes ago

      I had the same thought here, but it’s really just poorly stated, not wrong.

      The assumed context here is prevention of Cross-Site Request Forgery, which is a specific type of attack that only OCCURS via browsers, or similarly-trusted clients. In other words, attacks where this header is being forged by a non-browser client are mitigated by other security measures, such as authentication tokens.