A few methods of prevention that doesn't work :
Using a Secret Cookie
Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.
Only Accepting POST Requests
Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.
Checking Referer Header
An attacker can easily block the sending of the Referer header, and the HTTP RFC's make it clear that this header is optional. Browsers also omit the Referer header when they are being used over SSL.
Multi-Step Transactions
Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.
URL Rewriting
This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user's credential is exposed over the URL.
