A CSRF token is a value an application checks on a request to help prevent cross-site request forgery — an attacker making a visitor's browser perform an unwanted action using the visitor's existing login. In an authorized automation workflow, a valid session cookie may still be insufficient if the request omits the token the application expects.
Browsers attach eligible session cookies automatically. That convenience creates a risk: another site may cause a request to a service where the visitor is already logged in. A synchronizer token adds an unpredictable value that the server associates with the session and requires in the submitted request.
Applications often deliver the token in a hidden form field, page metadata, or a response used by their own frontend. The form or script returns it as a field or custom header. Copying a session cookie alone can leave this part of the application's request contract unsatisfied.
Synchronizer tokens may be issued per session or per request; there is no universal expiry interval or header name. A token from one browser session should not be assumed valid in another. Parallel workers that share mutable session state can also invalidate each other's expected tokens.
A double-submit cookie design compares a submitted token with a cookie value instead of storing a synchronizer token on the server. OWASP recommends a signed design bound to the session rather than a naive equality check. Token-based protection, SameSite cookies, and origin checks are related defenses with different validation rules.
If an allowed form workflow suddenly fails, check whether the session expired, the page supplied a new token, or the expected field was omitted. Keep the page read and subsequent submission in the same intended session, following the application's normal flow. A generic 403 alone does not identify CSRF as the cause.
Treat captured tokens and cookies as sensitive session material. Do not put tokens into URLs, shared logs, or reusable public examples. A CSRF token is not an API key, a CAPTCHA solution, or proof that automation is permitted; use the service's documented API when one exists.
How Crawlora handles this
Crawlora's API authentication follows its documented API contract. CSRF tokens matter when maintaining your own authorized browser sessions against a website; they should not be added speculatively to unrelated API requests or treated as a generic anti-bot fix.
Related reading
FAQ
No. The cookie usually identifies the session, while a CSRF token supplies an additional value the application validates for protected requests. Some designs use a separate CSRF cookie as part of that check.
No. Some applications use session tokens and others use per-request tokens. Follow the application's own behavior rather than assuming a fixed rotation rule.
No. Some cross-origin requests can reach a server without a CORS preflight even when the browser will not expose the response. Protecting actions requires appropriate server-side checks.
Beyond CSRF Token, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.