Test for CSRF Token Bypass with Burp Suite (2026)

Burp Suite can’t directly test for CSRF token bypass vulnerabilities; it’s a tool for manual and automated testing, meaning you need to tell it what to look for. The real vulnerability lies in how the application handles or validates its CSRF tokens, not in Burp itself.

Let’s see how you’d actually find this.

Imagine a simple web form that allows a user to update their profile:

<form action="/profile/update" method="POST">
    <input type="hidden" name="_csrf_token" value="aBcDeFg12345">
    <label for="email">Email:</label>
    <input type="text" id="email" name="email" value="user@example.com">
    <button type="submit">Update</button>
</form>

When a user submits this form, the server is supposed to check if the _csrf_token value matches a token it issued for that user’s session. If they don’t match, the request is rejected.

Here’s how you’d use Burp Suite to test for a bypass:

First, configure Burp to proxy your browser traffic. Browse to the page containing the form. In Burp’s Proxy -> HTTP history tab, find the POST request for /profile/update. Send this request to the Repeater tab.

In Repeater, you’ll see the original request. The _csrf_token is in the request body. The first, and most obvious, test is to simply remove the token entirely.

Test 1: Remove the CSRF Token

• Diagnosis: In Repeater, delete the line _csrf_token=aBcDeFg12345 from the request body.
• Action: Send the modified request.
• Why it works: If the application is poorly implemented, it might not require the token to be present, effectively bypassing the protection. A secure application will reject this request, likely with a 403 Forbidden or a specific error message.

Test 2: Submit an Invalid Token Format

• Diagnosis: In Repeater, change the _csrf_token value to something nonsensical, like invalidtoken.
• Action: Send the modified request.
• Why it works: Some validation routines might be overly simplistic and only check for the presence of a token, not its validity. A malformed token might still be accepted if the validation logic isn’t robust.

Test 3: Replay an Old Token

• Diagnosis: If you have a history of previous requests in Burp, find an older, valid _csrf_token from a previous form submission (even from a different user if you can capture it) and paste it into the current request.
• Action: Send the request with the old token.
• Why it works: If tokens are not properly invalidated on the server after use, or if the server doesn’t check if the token is current for the active session, an old token might be accepted.

Test 4: Use a Token from a Different Action

• Diagnosis: If the application uses CSRF tokens for multiple forms (e.g., /profile/update and /settings/change_password), try to capture a valid token from one form and use it in a request for the other form.
• Action: In Repeater, replace the _csrf_token value in the /profile/update request with a valid token captured from the /settings/change_password form submission.
• Why it works: The vulnerability here is if the server validates the token type or context incorrectly. If it just checks if a token exists and matches some valid token in its database, it might allow cross-context token reuse.

Test 5: Brute-force Token Values (Less Common, but possible)

• Diagnosis: This requires Burp’s Intruder. Select the _csrf_token parameter in Repeater and send it to Intruder. Clear all payload positions and add a payload position only for the _csrf_token value. In the Payloads tab, select Simple list and manually enter a few common or predictable token formats (e.g., a, aa, aaa, 0, 1, 00000000). You could also try brute_force_chars with a small character set if you suspect a very short token.
• Action: Start the attack. Monitor the response codes and lengths.
• Why it works: While modern CSRF tokens are usually cryptographically random and long, older or poorly implemented systems might use predictable or short tokens that can be guessed. If you get a successful response (e.g., 200 OK) with a guessed token, you’ve found a bypass.

Test 6: Bypass via Parameter Pollution or Manipulation

• Diagnosis: Sometimes, applications parse parameters in unexpected ways. In Repeater, try sending the _csrf_token twice, or with different casing if the server is case-insensitive in parameter handling. For example, try adding _csrf_token=valid_token&_csrf_token=new_invalid_token or _CSRF_TOKEN=valid_token.
• Action: Send these modified requests.
• Why it works: If the server’s parameter parsing logic is flawed, it might use the first or last instance of a parameter, or a case-insensitive match, in a way that bypasses the intended validation.

When you’re working with CSRF tokens, remember that the server-side implementation is key. Burp helps you craft and send the requests to probe for weaknesses in that implementation. The most common reason for a bypass is that the server doesn’t properly check if the token is present, valid, current, and associated with the user’s session and the specific action being performed.

If you manage to bypass CSRF protection for a sensitive action, the next error you’ll likely encounter is a generic server error, or perhaps the action will be completed successfully without any explicit error, indicating a successful exploit.