When creating a website, we tend to code the client-side and the server-side
together. We build the pages and forms a user will interact with on the
client-side, then build the server-side URLs that respond when the user
performs an action.
However, requests can be triggered to the server-side code from anywhere -
not just the client-side code we write. This is one of the most powerful
aspects of how internet is designed: it allows linking between sites.
But it is also the cause of a common security flaw,
cross-site request forgery (CSRF).
A CSRF attack occurs when a user is tricked into interacting with
a page or script on a third-party site that generates a malicious request
to your site. All your server will see is an HTTP request
from an authenticated user. However, an attacker takes control over the
form of the data sent in the request to cause mischief.
Imagine you run the micro-blogging service that allows your users
to tweep their opinions at each other in 280-character-sized chunks.

Mal is a hacker who has noticed that posts on your service
are created using GET requests. This means that all the information is
carried in the URL of the HTTP request.
Mal modifies the post-creation URL to include a malicious payload. Now he
has to find some way to get a victim to visit the URL in their browser.
Vic is one of your users. Mal has been able to guess his email address.
Mal sends Vic an email with a very tempting link, pointing to the crafted URL.
Vic clicks on the link.
Your server interprets the request as Vic writing a post, and creates a new
item on his timeline. This is not the action that Vic intended, but he
may not quite have noticed what just occurred.
The post is designed to be enticing enough that other users of your
site will click on it. When they do, they will be tricked in the same
way Vic was.
You now have a worm on your site, as each user who
clicks the link will open up a new set of potential victims. Bad news!