TL;DR
No, an attack that doesn’t change server state is not typically considered a Cross-Site Request Forgery (CSRF) attack. CSRF specifically relies on tricking a user into performing unwanted actions that modify data or settings on a web application they are authenticated with.
What is CSRF?
Cross-Site Request Forgery (CSRF) attacks exploit the trust a website has in a user’s browser. If you’re logged into a site, your browser automatically sends cookies along with requests to that site. A CSRF attack makes a malicious website send a request to that trusted site on your behalf, without your knowledge.
Why State Change Matters
The core of a CSRF attack is causing the server to perform an action it wouldn’t normally allow if initiated directly by the user. This usually means changing something – updating data, transferring funds, altering settings, etc. If no state change occurs, there’s generally no harm done and therefore isn’t classified as CSRF.
Examples
- CSRF (Bad): A malicious site creates a form that submits a request to your bank to transfer money. This changes the account balance – server state is altered.
- Not CSRF (Generally OK): A malicious site sends a request to read data from your profile page on another website. Reading doesn’t change anything; no server state is modified.
Scenarios where it gets tricky
Sometimes, the line can be blurry. Consider these points:
- Logging/Analytics: A malicious site sending a request to a website’s analytics endpoint (e.g., tracking page views) isn’t CSRF because it doesn’t alter user data or settings.
- Cache Manipulation: Attempts to force cache invalidation are generally not considered CSRF unless they lead to sensitive information disclosure or denial of service.
How CSRF Protection Works
CSRF protection focuses on verifying that requests come from the legitimate website, not a malicious one. Common techniques include:
- Synchronizer Token Pattern (STP): The server generates a unique token for each user session and includes it in forms. The server verifies this token with every request.
- SameSite Cookies: Cookies are only sent with requests originating from the same site, mitigating CSRF risks.
- Checking Referer Header: (Less reliable) The server checks the HTTP Referer header to see if the request originated from its own domain. This can be bypassed.
<form action="/transfer" method="post">
<input type="hidden" name="csrf_token" value="{{ csrf_token }}">
...
</form>
In Summary
While any unwanted network activity is concerning, a true CSRF attack requires a state change on the server. Attacks that only read data or perform non-modifying actions are not typically classified as CSRF and don’t require the same level of protection.