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: plain GET is Method Not Allowed, while /my-account/change-email?email=hacked@hacker.com&method=POST changes the email. 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 SameSite Lax bypass via method override through the endpoint and input recorded in the lab note. Plain GET is Method Not Allowed, while /my-account/[email protected]&_method=POST changes the email.

What I observed

plain GET is Method Not Allowed, while /my-account/[email protected]&_method=POST changes the email.

Lab description asks for a CSRF email change hosted on the exploit server.
Lab description asks for a CSRF email change hosted on the exploit server.
My Account shows the email-change form before method-override testing.
My Account shows the email-change form before method-override testing.
A plain GET to /my-account/change-email is rejected with 405 Method Not Allowed.
A plain GET to /my-account/change-email is rejected with 405 Method Not Allowed.

Why it is vulnerable

Plain GET is Method Not Allowed, while /my-account/[email protected]&_method=POST changes the email. 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.

A top-level GET to /my-account/change-email?email=...&_method=POST is accepted and returns 302 Found while the Lax session cookie is sent.
A top-level GET to /my-account/change-email?email=...&_method=POST is accepted and returns 302 Found while the Lax session cookie is sent.
My Account displays abc@gmail.com, confirming the GET navigation was processed as the POST email-change operation.
My Account displays [email protected], confirming the GET navigation was processed as the POST email-change operation.
The exploit-server script navigates the victim to /my-account/change-email?email=hacked@hacker.com&_method=POST.
The exploit-server script navigates the victim to /my-account/[email protected]&_method=POST.
The Academy banner for “SameSite Lax bypass via method override” shows Solved.
The Academy banner for “SameSite Lax bypass via method override” shows Solved.

Verification

The lab is confirmed when plain GET is Method Not Allowed, while /my-account/[email protected]&_method=POST changes the email. 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