Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.

Overview

The exercise isolates a CSRF enforcement gap: gET is rejected and a modified token is invalid, but deleting the entire csrf parameter from POST /my-account/change-email returns 302. The important evidence is the browser’s cookie and navigation behavior, not merely that a cross-site form can be submitted.

Lab objective/setup

Exercise CSRF where token validation depends on token being present through the endpoint and input recorded in the lab note. GET is rejected and a modified token is invalid, but deleting the entire csrf parameter from POST /my-account/change-email returns 302.

What I observed

GET is rejected and a modified token is invalid, but deleting the entire csrf parameter from POST /my-account/change-email returns 302.

Lab description identifies an email-change CSRF vulnerability where the token check can be bypassed.
Lab description identifies an email-change CSRF vulnerability where the token check can be bypassed.
My Account shows the email-change form before testing token omission.
My Account shows the email-change form before testing token omission.
A GET request to /my-account/change-email is rejected with 405 Method Not Allowed.
A GET request to /my-account/change-email is rejected with 405 Method Not Allowed.

Why it is vulnerable

GET is rejected and a modified token is invalid, but deleting the entire csrf parameter from POST /my-account/change-email returns 302. The application passes that value into the security-sensitive operation without the context-specific validation or encoding needed to prevent this result.

Walkthrough in the authorized PortSwigger lab

Recreate the account-change flow, establish the normal request’s token and cookie requirements, then alter only the method, token presence, cookie age, redirect path, or sibling-origin step named in the evidence. The goal is to show exactly where the browser still supplies authority to the forged request.

The HTTP history shows POST /my-account/change-email after removing the csrf parameter; email remains in the body and the server returns 302 Found.
The HTTP history shows POST /my-account/change-email after removing the csrf parameter; email remains in the body and the server returns 302 Found.
My Account displays abc@example.com, confirming the POST succeeded when the csrf field was absent.
My Account displays [email protected], confirming the POST succeeded when the csrf field was absent.
The exploit-server editor contains an auto-submitting POST form with the email field and no csrf input.
The exploit-server editor contains an auto-submitting POST form with the email field and no csrf input.
The Academy banner for “CSRF where token validation depends on token being present” shows Solved.
The Academy banner for “CSRF where token validation depends on token being present” shows Solved.

Verification

The lab is confirmed when gET is rejected and a modified token is invalid, but deleting the entire csrf parameter from POST /my-account/change-email returns 302. The captured result and the Academy solved state provide the verification; an ordinary status code alone does not.

Impact and defensive lesson

A production attacker could change victim account data while relying on ambient cookies. Validate CSRF tokens on every state-changing route and method, bind them to the authenticated session, set deliberate SameSite attributes, and remove redirect or sibling-origin gadgets that turn same-site navigation into cross-site request authority.

References