CSRF defined.
CSRF (Cross-Site Request Forgery) is an attack that tricks a logged-in user's browser into sending an unwanted request to a site they are authenticated with, using the session they already hold.
How a CSRF attack works
CSRF abuses the fact that browsers attach a site's cookies to every request to that site, including ones triggered from a different site. Suppose you are logged in to your bank and, in another tab, you visit a malicious page. That page can silently make your browser POST to the bank, and because your session cookie is sent automatically, the bank sees an authenticated request and acts on it, moving money or changing a setting you never asked for. The attack works precisely because the action depends on an ambient session the victim already holds.
The standard defenses break that assumption: a CSRF token, a secret value the real page embeds and the forged request cannot know, plus SameSite cookies and origin checks that reject requests coming from another site.
It is worth being clear about where this does and does not apply, which is exactly the case for a public form endpoint.
CSRF needs a session to hijack.
No session to ride
CSRF steals the authority of a logged-in session. A public form endpoint has no user session to hijack, so the classic attack has nothing to borrow.
A public key, not a secret
A form key identifies which account a submission belongs to. It is meant to be in your HTML, so exposing it grants no privilege to forge anything.
The real risk is spam
Because the endpoint is open by design, the threat is bulk junk, not forged authenticated actions. That is a spam problem, met with different tools.
Related questions
Not in the classic sense. CSRF works by riding a victim's authenticated session to perform an action as them. A public form endpoint has no login and no privileged session behind it, so there is nothing for a forged request to hijack, since anyone can already POST to it by design. The concern shifts from forged actions to unwanted volume, which is a spam and rate-limiting question.
See how FormWire filters unwanted submissions →Yes. The key is a public identifier that routes a submission to the right account, not a password that unlocks your data. It cannot read stored submissions or sign anyone in, so having it visible in your form's markup grants an attacker no leverage.
With a CSRF token the legitimate page embeds and the server checks, so a cross-site request that cannot know the token is rejected. They pair it with SameSite cookies and origin or referer checks, which is a separate mechanism from the CORS rules a browser applies to cross-origin reads.
A CSRF token is technically a hidden field, but a honeypot hidden field solves a different problem: it catches spam bots, not forged authenticated requests. On a public form the honeypot is the relevant hidden field, because spam, not CSRF, is the threat you actually face.
Want to see it working?
Read the docsCollect submissions on a safely public endpoint.
Free tier forever. No credit card required.