CSRF token

#How it works

1. The user's browser holds a session cookie for the site.
2. The site's page includes a token, in a hidden form field, a meta tag or a response header.
3. When the page sends a change request, it includes the token.
4. The server compares the token with the value it expects. A missing or wrong token gets the request rejected.

#Why it matters for AI agents

Writes on many sites need a current token. A request without one can fail even when the cookies are valid. An agent that makes writes must therefore obtain the token from the same session that sends the request.

#The three credentials compared

#Wield and CSRF tokens

A recipe can read a token from the site's page before its steps run. The recipe format calls this auth.derive. The value is a secret, so Wield replaces it with [redacted] in results, logs and error messages. Any write still waits for your Allow.

#Related terms

• Cookies and sessions
• Bearer token
• Internal API

#FAQ

#What is the difference between a CSRF token and an auth token?

A CSRF token proves that a request came from the site's own page. It does not identify the user. An auth token, such as a bearer token, identifies the caller to an API. The two do different jobs, and a site can require one, the other, or both.

#Why do POST requests need a CSRF token?

A POST usually changes data: it creates, updates or deletes something. Browsers attach the user's cookies to requests for the site, including requests that another site starts. The token makes such a forged request fail, because the other site cannot read the token.