CSRF protection only for requests with side effect (POST, DELETE, PUT)?

As far I understand Cross-Site Request Forgery attacks they "only" used to change state on Server side.

Assume:

• I have a REST Web Application, and I am sure that HTTP GET requests does开发者_如何学C not change my application persistent state (no side effects)
• I use a session-specific key to authorize the requests

Do I need to verify the session-specific key for GET Request?

---

It's not really a question of the request method (GET and POST can both make changes to persistent state), as each can be exploited by various CSRF attack vectors. When you talk about a "session-specific key", I assume you're talking about a synchroniser token pattern (more on this in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF)). Obviously this is intended to protect against the browser making unauthorised requests on your behalf under the orchestration of a third party.

So the question is really "Does my app require protection against CSRF?" It sounds like there's no change to persistent data in your app anyway so on the surface of it, the answer is "no". You generally only find anti-request forgery tokens in places where a CSRF attack would have an adverse impact so it sounds to me like it's something you don't need to worry about.