Skip to content

Debugging 403 Permission and CSRF Failures

A 403 means the server recognized the request as authenticated but refused it anyway. The most common cause is a missing or stale anti-CSRF token. The next most common is permission: the recording was done with an admin user but the test case is replaying as a regular user. The third is anti-bot defenses (CAPTCHA, rate limiting, IP reputation) treating the load test as an attack.

For systematic debugging that gets you here, see Debugging Failed Replays. 403 errors are usually unconfigured dynamic fields, specifically a CSRF token that should have been extracted from a previous response.

Symptom

Visual indicators:

  • Replay View: Authenticated requests succeed, then a 403 appears on a state-changing request (POST, PUT, DELETE)
  • Content View: Response shows "Forbidden", "CSRF validation failed", or "Invalid token"
  • Headers View: Request body or headers include a CSRF token that doesn't match what the server expected

Example failure sequence:

✓ GET /account (200 OK) - User account page loads
✓ POST /login (200 OK) - Login succeeds
❌ POST /transfer (403 Forbidden) - CSRF validation failed

Diagnostic Steps

Step 1: Identify the failing transaction's token

  1. Open Headers View for the failed 403 transaction
  2. Look in Request Headers for header names like X-CSRF-Token, X-XSRF-Token, X-Requested-With, or any custom token header
  3. Look in the Request Body (POST data) for form fields named authenticity_token, csrf_token, __RequestVerificationToken, or similar
  4. If you find one of these, that's the value the server is validating against

Step 2: Compare recorded vs. replayed token

  1. Switch the editor to show the original recording for the same transaction
  2. Compare the token value in the recording to the value in the replay
  3. If the values are identical: ASM didn't correlate the token. It's sending the recorded value instead of a fresh one. Go to Fix 1: Re-Run ASM.
  4. If the values differ but the replay is still rejected: The token was extracted but possibly from the wrong source, or the server expects it in a different field. Go to Fix 2: Trace the Token Origin.

Step 3: Check for non-CSRF causes

If no token is involved, the 403 is probably one of:

  • Permission: The replay user account doesn't have permission for this operation. Try a different account.
  • Rate limiting: Hitting the same endpoint too fast trips bot protection. Add think time or contact ops for a test-account exemption.
  • Anti-bot detection: WAF / CDN / bot-defense rules treat synthetic traffic as an attack. See The Anti-Bot Reality.

Solutions

Fix 1: Re-Run ASM

CSRF tokens are exactly what ASM is for. Run the full Configure for Replay wizard, or re-run ASM standalone via Right-click → Configure → Application State... if hostnames are already restricted.

After ASM, verify the token field has a gray background in the Fields View of the failing transaction, and that its datasource is Extractor[N] or User Variable, not "Text Constant."

Fix 2: Trace the Token Origin

If ASM ran but the token is still wrong, the extractor probably grabbed the token from the wrong response. CSRF tokens are usually emitted in the HTML response that contains the form, not in a JSON response that comes later. Use the AI assistant's find_value_origin to locate the first response containing the token value, then create or fix an extractor on that response. See Custom Extractors for the manual extractor walkthrough.

Fix 3: Use a Different User Account

If the issue is permission, configure the test case to use an account that has the required permissions. For multi-user load tests, build a dataset of accounts that all have equivalent permissions for the workflow under test.

Fix 4: Coordinate with Security on Rate Limits

If you're hitting rate limits or anti-bot defenses, you can't fix that in the test case alone. Work with the security team to whitelist the load generator's IP range, exempt test accounts from CAPTCHA challenges, or set up a separate internal test environment with relaxed defenses.

Still Failing?

Ask the AI

Replay fails with 403 on the POST /transfer transaction. I see an
authenticity_token in the request body. The token in the replay
matches the one in the recording exactly. What's wrong?

If the AI sees an identical token in both, that's your evidence ASM didn't correlate it: the recorded value is being sent verbatim. Return to Fix 1.