What is CSRF and how is an application protected against forged requests?
Published on 2026-10-20 by frfrand
Ataques CSRF explicados con cookies, acciones involuntarias, tokens anti-CSRF, SameSite y defensas del servidor.
CSRF is an attack that attempts to exploit the fact that an authenticated person's browser can send requests to a site without that person having intended to perform the action. It stands for Cross-Site Request Forgery, or cross-site request forgery.
The key is that a website can recognize a session via cookies. An attacker tries to cause the browser to send an operation leveraging that identity.
The example of an order you never gave
Imagine you log into your bank and leave the session open. Then you visit an unknown page that attempts to trigger a request to modify some data on your account.
If the bank accepted the operation solely because it arrived with a valid cookie, it could treat an unwanted action as if you had requested it. A correct design checks something more than "there is an active session."
It does not mean that any site can read your banking data: the same-origin policy limits many reads between pages. Preventing reading a response and preventing a request from being sent are different problems.
What role do cookies play?
The browser can attach cookies to requests based on the domain, cookie policies, and browsing context. This convenience allows maintaining sessions, but also requires protecting sensitive actions.
Attributes such as SameSite help restrict when cookies are sent across sites. They are a useful defense, although they do not replace all server-side checks and require choosing a policy appropriate for the product.
What is an anti-CSRF token?
Many applications generate a value that the attacker should not know and require it to appear in operations that modify information. The server verifies that it corresponds to the expected session or context.
Frameworks such as Django include protections and verification mechanisms for forms and state-changing requests. But they still depend on correct configuration: disabling protections to "make the frontend work" can create a serious problem.
Does CORS solve CSRF?
No. CORS regulates certain cross-origin accesses from browsers, but it was not designed to replace an anti-CSRF defense. A request can produce effects on the server even when the browser does not allow reading its response.
It is also not advisable to confuse CSRF with XSS. In XSS, the attacker manages to execute untrusted code within the context of a page. Both problems can be related, but their causes and mitigations are different.
What operations need attention?
Changing a password, modifying an email, transferring funds, adding users, or deleting records are examples of actions whose legitimate origin must be verified.
GET requests, by convention, should not modify state. If visiting a URL triggers a deletion, besides the possible CSRF there is an incorrect HTTP design decision.
How to check protection?
Test that a legitimate form works and that an operation without the required token or context is rejected. Also check what happens when the session expires and when the request comes from an unexpected origin.
Do not perform security tests against third-party services without permission. A own test environment allows checking configurations without putting real data at risk.
What does this mean in ArduMaker?
If you host on an ArduMaker VPS an application that uses session cookies, its backend must apply appropriate CSRF defenses. The fact of deploying it under HTTPS does not automatically eliminate that risk.
In summary: CSRF attempts to turn a legitimate user's session into an operation they did not authorize. Defense requires validating the request's intent, in addition to identity.
Sources: OWASP CSRF Prevention Cheat Sheet · Django CSRF Protection.