The attacker crafts a malicious request (e.g., a hidden form submission, an image tag, an AJAX request) that performs an action on the victim's behalf (e.g., change password, transfer money, make a purchase). The attacker then embeds this malicious request on a website they control (or through phishing emails). When the victim, who is already authenticated to the target vulnerable application, visits the attacker's malicious site, their browser automatically includes their valid session cookies for the target site with the forged request. The target application receives this request, sees the valid session cookies, and executes the action, believing it was legitimately initiated by the victim.

You are logged into your online banking website. An attacker sends you an email with a seemingly innocent image (or a link to a malicious website). Unbeknownst to you, the image URL in the email is . If you open this email while still logged into your bank account, your browser will attempt to load the "image." Because it's a request to yourbank.com, your browser automatically attaches your banking session cookie. The bank's server receives the request, sees your valid cookie, and proceeds to initiate a transfer of 1000 units of currency to the attacker's account, all without any direct interaction from you beyond opening the email.

○ CSRF Tokens (Synchronizer Token Pattern): This is the most effective and widely adopted defense. For every state-changing request (e.g., form submission, AJAX request that modifies data), the server generates a unique, unpredictable, and user-specific CSRF token. This token is then embedded as a hidden field within the HTML form or as a custom header in AJAX requests. When the user submits the form or makes the request, the server verifies that the received token matches the one it originally generated for that user's session. Since an attacker, due to the Same-Origin Principle, cannot read the content of the legitimate form or execute JavaScript on the target domain to obtain this unique token, they cannot forge a valid request.

○ SameSite Cookie Attribute: This is a powerful, browser-enforced security feature. By setting the SameSite attribute for cookies (especially session cookies) to Lax or Strict, you can control when cookies are sent with cross-site requests.

○ Referer Header Validation (Less Reliable): The server can check the HTTP Referer header to ensure that the request originated from the legitimate domain of the application itself. However, this is considered a weaker defense as Referer headers can be suppressed by browsers, or in some cases, spoofed by attackers.

○ Custom Request Headers: For AJAX requests, using custom HTTP headers (e.g., X-Requested-With) can provide some CSRF protection if the server validates the presence of such headers, as browsers typically do not allow custom headers in simple cross-site requests.