Get the next one in your inbox.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.
CSRF sounds scary, but a public contact form has a very different risk profile than an authenticated settings form. Here's what actually matters for each.
Get an instant summary, key takeaways, action items, and answers to your questions about this article.
CSRF (Cross-Site Request Forgery) tricks a logged-in user's browser into submitting a request they didn't intend to make, using their existing session. A public contact form with no login has no session to hijack, so CSRF matters much less there than on authenticated forms like account settings, where the same trick could change a password or email address without the user's knowledge.
Cross-Site Request Forgery is a trick, not a break-in. It doesn't steal your password or bypass your login — it abuses the fact that your browser automatically attaches your session cookies to any request sent to a site you're logged into, regardless of which page told your browser to send that request. If an attacker gets you to load a page (or an image tag, or an auto-submitting form) that fires a request at a site where you're already logged in, that request goes out carrying your session, looking completely legitimate to the server.
A public contact form doesn't require login. There's no session to ride along on, and no account-level action being performed. If someone forges a submission to your contact form from another page, the worst outcome is an unwanted message landing in your inbox — annoying, but functionally indistinguishable from spam. It's not nothing, but it's not the kind of security incident CSRF protection exists to prevent, and it's better addressed with the spam-protection tools you'd use anyway (CAPTCHA, honeypot fields, rate limiting).
The picture changes completely once a form performs an authenticated action — updating an email address, changing a password, modifying billing details. Now a forged request isn't just noise; it's an attacker using a logged-in user's own session to make a change on their behalf, without them ever entering credentials or seeing what happened. This is the scenario CSRF protection is actually built for, and it's worth taking seriously anywhere a form sits behind a login and changes something that matters.
The practical takeaway: don't skip CSRF thinking entirely just because your public form is low-risk, but don't over-engineer a contact form either — save the token-based defense for the forms that actually sit behind a login and do something sensitive.
Generally not for the classic CSRF risk, since there's no authenticated session to abuse — the worst a forged submission can do is send you an unwanted message, which is really a spam problem rather than a security breach. It's still reasonable to add basic origin checking, but token-based CSRF protection is more relevant once a form performs an authenticated, sensitive action.
The two common approaches are checking the request's Origin or Referer header against your own domain, and issuing a unique CSRF token when the form is rendered that must be submitted back and validated server-side. Origin checking is simpler and often sufficient for lower-risk forms; token validation is the stronger, standard defense for authenticated, sensitive actions.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.