Cross-Site Request Forgery (CSRF): Basics & Protection

Key questions about cross-site request forgery:

• What is CSRF?
• Who is affected by CSRF?
• When and where does CSRF tend to occur?
• Why is CSRF dangerous, and how do these flaws arise?
• How can you detect and prevent CSRF?

The sections below look at each of these points in detail.

1. Introduction and background

Cross-site request forgery, often shortened to CSRF, is a type of attack. The attacker makes the browser of a logged-in user perform unwanted actions on a website. The user is logged in to that site. The attack abuses the trust between the user and the web application to send harmful requests.

Classic attacks most often use flaws in software. Cross-site request forgery works in a different way. It takes advantage of the fact that browsers send login cookies or session tokens on their own once the user is logged in.

In the past, people first talked about flaws in web applications in terms of SQL injection or cross-site scripting (XSS). As web applications grew more modern, request tampering such as CSRF also came into focus. Today, users are active on many websites as part of their daily routine. Sites are more and more linked. This gives attackers many chances to carry out CSRF attacks.

The problem is not limited to sites with sensitive banking or financial data. It also affects:

• everyday communication portals
• social networks
• web applications where users can carry out simple transactions

2. How cross-site request forgery works

A forged form is the classic example to explain CSRF. The attacker builds a web page with a form. The form sends a request to a target website where the user is logged in. This happens when the page loads, or through a hidden trick in the background. The browser sends the request with valid cookies on its own. So the attacker gets what only the user should have been able to approve. The attacker may then be able to:

• carry out transactions
• change settings
• read private data

Note that CSRF attacks do not always need a flaw in the software. They rely on the way the web browser handles normal requests and logins. Modern browsers have APIs and security policies that are largely standard. But if the server skips checks, such as checking a CSRF token, the door to these attacks is wide open.

In many attacks, the attacker tries to get the user to visit a page built for this purpose. Once the user is there, a real action runs on another website in the background. The user does not notice. Often, the user finds out too late that their data was exposed or that someone started transactions in their name. The damage can be financial. It can also harm trust in online services for a long time.

3. A closer look at how attackers get in

Attackers often combine several tactics to make sure their attack works. The most common ones are:

• Forms sent without the user: Attackers can tamper with a website in the background. They use prepared links, GET requests or POST requests that are sent on their own.
• Image tags, iframes and JavaScript: Attackers often embed hidden iframes that run actions on a target page. It does not matter whether these actions use GET or POST requests.
• Social engineering: Besides pure tech methods, attackers often use mind tricks. They lure users into clicking harmful links or visiting unsafe pages. For example, the attacker may post a link that looks harmless on a popular social network. In the background, the link triggers a critical transaction.

People often ask:

• Who is often the target of a CSRF attack? Users who carry out many sensitive actions in several browser sessions are most at risk. Admins and developers who work where protection is weak are also frequent targets.
• What makes CSRF so dangerous? The main danger is that attackers can tamper with large amounts of data and trigger transactions. This can harm users' trust in web applications for good.

4. Technical details: how does a CSRF attack work?

On a technical level, a CSRF attack most often starts with a cross-site request. The attacker can trigger it with tampered HTML elements. One example is a form whose action attribute points to a certain URL. That URL causes a critical change on the target platform. Often there is no extra login step here, because the browser already has valid session data.

Anti-CSRF tokens are a core part of the defense against such attacks. They work like this:

1. The server creates a special token on the fly and adds it to a form.
2. The browser sends the token along when the user submits the form.
3. The server checks whether the token matches the one it created.
4. If the two do not match, the server rejects the request as invalid.

The token adds one more barrier. It makes it much harder for an attacker to carry out cross-site request forgery.

5. Protective measures and best practices

You can protect against CSRF attacks with many technical and organizational measures. The most effective ones are:

a) Use synchronizer tokens

Anti-CSRF tokens in forms and API calls are the most common protective measure. These tokens should be random and bound to each user session. Then an attacker cannot simply guess or reuse the right token.

b) Use SameSite cookies

Modern browsers support the "SameSite" attribute for cookies. If you set it, the browser does not send cookies in a third-party context. This makes it harder for an attacker to reach session data through another website.

c) Check the HTTP method

Do not handle requests that trigger critical functions via GET. Use POST or other HTTP methods instead. You can secure POST requests much better, for example with CSRF tokens.

d) Use CAPTCHAs

CAPTCHAs are mainly used to stop spam. But in some cases they can also act as one more barrier against automated requests. They need a human to take part, so a CSRF attack gets even harder.

e) Regular security reviews

Regular code audits and penetration tests help you find and fix flaws fast. Keep monitoring and updating the web application code and the way you handle logins.

f) Staff training and awareness

Tech measures are not all that counts. In companies, staff, developers and admins should get regular training on the risks of CSRF and other cyberattacks. The more aware they are, the harder it is for attackers to succeed.

Questions about protective measures:

• How can we stop a CSRF attack from working? Synchronizer tokens, SameSite cookies and strict checks on the server side cut the risk of CSRF a lot.
• What happens if a CSRF attack works? Attackers may carry out transactions without the user's consent. This can lead to data loss, financial damage or a loss of user trust.

6. Practical examples and real cases

A few examples from practice show how real the danger of cross-site request forgery is. Time and again, attackers have caused major damage. They planted harmful links in popular forums or on social media platforms. A typical case involves a function that changes something, such as a payment, a password change or an email change. If the site calls it without a CSRF token or SameSite cookies, attackers can trigger it in the name of logged-in users.