Cross-Site Request Forgery (CSRF) protection stops hostile sites from smuggling unwanted actions into authenticated sessions, such as changing account details or submitting forms invisibly. Including a unique CSRF token in each state-changing request ensures the action originates from the legitimate application context rather than an attacker-controlled page.

Most web frameworks generate a CSRF token per session or per request, attach it to the form markup or a response header, and verify it alongside the usual cookies. A scripted client such as cURL must therefore behave like a browser: capture cookies, parse the token from the response, and replay both together in the next POST or PUT request so the server accepts the action.

Tokens are often short-lived, bound to a specific cookie, and sensitive enough that command history or logs should not expose them in plain text. The approach below assumes a Linux shell with cURL and standard text utilities, targets a hidden input field named csrf_token in an HTML login form, and relies on HTTPS with a trusted certificate to keep the token and credentials confidential in transit.

Related: How to save cookies from cURL request
Related: How to send HTTP data with cURL

Steps to extract and use CSRF tokens with cURL:

  1. Prepare a working directory on a Linux system for temporary HTML and cookie files. 
    $ mkdir -p /tmp/csrf-demo
$ cd /tmp/csrf-demo
$ pwd
/tmp/csrf-demo

    Using a disposable directory under /tmp keeps token files and cookies away from long-lived project folders.

  2. Fetch the login form that embeds the CSRF token while storing server cookies in a cookie jar file. 
    $ curl --silent \
  --cookie-jar cookies.txt \
  --output login.html \
  "https://www.example.com/login"

$ head -n 6 login.html
<!doctype html>
<html>
<form action="/authenticate" method="post">
  <input type="hidden" name="csrf_token" value="12345abcde">
  <input type="text" name="username">
##### snipped #####

    The --cookie-jar option writes all received cookies into cookies.txt so the hidden CSRF token remains tied to the same server-side session for later requests.

  3. Extract the hidden CSRF token from the saved HTML file into a shell variable using a regular expression. 
    $ TOKEN=$(grep --only-matching --perl-regexp 'name="csrf_token" value="\K[^"]+' login.html)
$ printf 'Extracted CSRF token: %s\n' "$TOKEN"
Extracted CSRF token: 12345abcde

    The pattern targets the name="csrf_token" field; adjust the attribute name or selector if the application uses a different parameter or markup structure.

  4. Submit the authentication POST request with username, password, cookies, and the captured CSRF token. 
    $ curl --silent --show-error \
  --include \
  --cookie cookies.txt \
  --data-urlencode "username=user" \
  --data-urlencode "password=pass" \
  --data-urlencode "csrf_token=$TOKEN" \
  "https://www.example.com/authenticate"
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=utf-8
##### snipped #####

    Credentials and token values supplied directly on the command line may leak via shell history or process listings; prefer environment variables, prompt-based input, or restricted scripts to reduce exposure.

  5. Request a protected page using the same cookie jar file to verify that authenticated access now succeeds. 
    $ curl --silent \
  --cookie cookies.txt \
  "https://www.example.com/account" | head -n 4
<!doctype html>
<html>
<title>Account overview</title>
<h1>Welcome, user</h1>

    Success indicators include an HTTP 200 OK status, account-specific content, and the absence of redirects back to the login form or HTTP 403 Forbidden responses.

  6. Remove temporary files once the workflow finishes so tokens and cookies do not linger on disk. 
    $ rm --force login.html cookies.txt

    Leaving cookie jars and HTML captures with embedded CSRF tokens on multi-user systems increases the risk of session hijacking by local attackers with filesystem access.

Discuss the article:

Comment anonymously. Login not required.