Cross-site request forgery (CSRF) makes a logged-in user's browser send a request they did not intend, such as changing their email address or transferring money. The browser automatically attaches the user's cookies, so the application thinks the request is genuine.

How it happens

The attacker hosts a page with a hidden form or image that targets your site. When a logged-in user visits it, the browser submits the request with their session cookie. Without a CSRF token or a strict SameSite cookie policy, the server cannot tell the forged request from a real one.

Why it matters

• Unwanted account changes, including email or password changes that lead to takeover.
• Unauthorised purchases, transfers or admin actions.
• Abuse of any state-changing feature.

How to prevent it

• Use anti-CSRF tokens that are unpredictable and bound to the user's session.
• Set session cookies with SameSite=Lax or Strict.
• Require re-authentication for sensitive actions.
• Do not accept state-changing requests over GET.

How Vooki Pro helps

• Tests for missing, predictable and session-unbound CSRF tokens, and for CSRF on JSON endpoints.
• Checks cookie flags including SameSite, Secure and HttpOnly.
• Can test state-changing methods (POST, PUT, DELETE) with a safety guard, and you can switch this off for sensitive environments.
• Flags each issue with the affected form or endpoint and a clear fix.

Frequently asked questions

Do SameSite cookies fully prevent CSRF?

SameSite=Lax or Strict blocks most CSRF, but CSRF tokens are still recommended, especially for older browsers and same-site attack paths.

Are JSON APIs vulnerable to CSRF?

They can be, if they accept simple content types or rely only on cookies for authentication. Test JSON endpoints too.

Related: Insecure file upload · JSON Web Token (JWT) vulnerabilities