A cross-site request forgery (CSRF) attack makes unauthorized actions on behalf of a logged-on user thus abusing the trust of the web application in the user. The actions are often completely indistinguishable from the actual clicks and text inputs of the user. Attackers target sites and web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize actions. The attacker inserts malicious code into a browser plugin or banner ad, which then are used to launch CSRF attacks. Cross-site scripting can also be used to launch CSRF attacks. CSRF is essentially an in-browser session hijacking attack.

To mitigate CRSF attacks, users should log out of sites when finished with what they wanted to do on that site. Browser extensions can be added to browsers by providing a default deny policy or removing authentication information for cross-site requests, but it can limit what the user can do on some sites.

Web developers can use a number of countermeasures to combat CSRF attacks. First, GET requests should not be used to send user actions to the server and instead only be used for static pages and queries. Web application should generate a one-time token just like when trying to prevent a replay attack so the attacker cannot use a previously observed URL to trigger an action on behalf of the user. Session cookies should have a limited lifetime; users should be logged off after a period of inactivity. Check the HTTP Referrer header to see if the request is coming from an authorized page. (The referrer identifies the address of the webpage from which a link was followed.) Some type of challenge-response should be used to ensure that the user is human and not an automated program. Examples of challenge-response methods are re-prompting the user to enter his password, answering previously set challenge questions, or using a distorted image (called a CAPTCHA) with characters that the user must type in.

Example of a CAPTCHA