Absence of Anti-CSRF Tokens

No anti-CSRF tokens were found in an HTML submission form. Without these tokens, the application cannot distinguish between a legitimate request made by the user and a forged request crafted by an attacker. This leaves all state-changing operations exposed to cross-site request forgery, where a malicious site tricks the victim’s browser into submitting authenticated requests on the attacker’s behalf.

An attacker can exploit the absence of anti-CSRF tokens by embedding a hidden form or crafted link in a page they control, causing the victim’s browser to automatically send an authenticated request to the vulnerable application. This can lead to unauthorized actions performed under the victim’s identity, such as changing account credentials, transferring funds, or modifying application settings. The risk is amplified when the application also contains cross-site scripting (XSS) flaws, as XSS can be used as a platform to launch CSRF attacks within the same-origin policy.

Generate a unique, unpredictable token for each user session or for each form, embed it as a hidden field in every HTML form, and validate it on the server side before processing any state-changing request. Reject the request if the token is missing or does not match the expected value.

Use a vetted library or framework that provides built-in CSRF protection, such as the OWASP CSRFGuard, Spring Security’s CSRF support, or the Django CSRF middleware. These implementations handle token generation, injection, and validation automatically.

As a defense-in-depth measure, apply the SameSite attribute to session cookies to prevent the browser from sending them in cross-origin requests. Additionally, never use GET requests for operations that change server-side state, and verify the Origin or Referer header as a supplementary check.

Ensure the application is free of cross-site scripting vulnerabilities, because most CSRF defenses can be bypassed when an attacker can execute scripts in the context of the target origin.