What is a CSRF attack? Prevention and security measures

Cross-Site Request Forgery (CSRF) exploits trusted web sessions, allowing attackers to perform unauthorized actions on behalf of users, often without their awareness. Fortunately, there are strategies to prevent these attacks.

In this article, you’ll learn:

• What is a CSRF attack, and how does it impact users.
• Key examples of CSRF vulnerabilities.
• Proven methods to prevent CSRF attacks.
• How WorkOS can safeguard your web apps.

Let’s start by explaining what a CSRF attack is.

What is a CSRF attack?

A CSRF attack is a type of security vulnerability that tricks a user's browser into performing unintended actions on a web application where the user is already authenticated.  

It takes advantage of the existing trust the website has in the user’s browser to initiate unauthorized actions without the user’s consent. This could mean changing account settings or making unauthorized transactions, all while the user is completely unaware.

CSRF attacks aim to cause a state change on the server, such as changing the victim’s email address or password, or purchasing something. This is because forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does.

How does CSRF work?

CSRF takes advantage of how browsers automatically send session cookies or credentials with every request when a user is logged in, such as when updating a profile.

The attack involves tricking the browser into sending these authenticated requests without the user's awareness.

An attack scenario might look like this: 

1. The attacker sends a crafted link or embeds a malicious request, aiming to trick the user into clicking or loading it.
2. When the user does this, their browser sends that request to the targeted web app — complete with their session cookies — making it appear as though the user intentionally initiated the request.
3. The application processes the request, thinking the user wants to log in to the attacker's account.
4. The user is logged into the attacker's account on the application.

Essentially, the attacker is forging requests on the user's behalf, relying on the trust the web app has in the user's existing session.

Examples of common CSRF vulnerabilities

CSRF attacks commonly appear in several forms, such as:

• Changing account settings: An attacker could trick a user into unknowingly changing their email address, password, or other account details by sending a crafted request.
• Unauthorized fund transfers: A malicious request could trigger a money transfer from the user's account to the attacker’s account, exploiting the trust between the user’s session and the banking site.
• Form submission vulnerabilities: Attackers can manipulate forms to submit data on the user's behalf, such as posting unwanted content or changing user preferences without their consent.

How to prevent CSRF attacks

Use anti-CSRF tokens

Anti-CSRF tokens are a key strategy for preventing CSRF attacks. A nonce — a unique token generated per session — adds an extra layer of protection by ensuring each request is one-time-use and verifying its authenticity.

With WorkOS you can generate a nonce value during an OAuth flow as follows:

	
const WorkOS = require('@workos-inc/node').default;
const workos = new WorkOS('your_workos_api_key');

app.get('/auth', (_req, res) => {
 const nonce = generateNonce();

 // The user's organization ID
 const organization = 'org_123';

 // The callback URI WorkOS should redirect to after the authentication
 const redirectURI = 'https://dashboard.my-app.com';

 const authorizationUrl = workos.sso.getAuthorizationURL({
   organization,
   redirectURI,
   clientID,
   state: nonce,
 });

 res.redirect(authorizationUrl);
});
	

When the user returns to your application, validate the nonce to ensure it is legitimate. Hash the returned nonce and compare it to the hashed version stored in the session cookie. If a potential CSRF attack is detected (i.e., if the values don’t match), authentication fails.

	
app.get('/auth/callback', async (req, res) => {
 const returnedState = req.query.state as string;
 const hashedReturnedState = hashNonce(returnedState);

 // Get your cookie value
 const storedHashedNonce = req.cookies['hashed_nonce'];

  // Define your client ID
 const clientID = 'your_client_id_here';

 if (hashedReturnedState === storedHashedNonce) {
   const code = req.query.code as string;

   try {
     const profileAndToken = await workos.sso.getProfileAndToken({ code, clientID });
     // Use the information in `profile` for further business logic.
     res.redirect('/');
   } catch (err) {
     res.status(500).send('WorkOS profile and token retrieval failed');
   }

 } else {
   // Potential CSRF attack detected
   res.status(403).send('Authentication failed');
 }
});
	

Implement SameSite cookies

The SameSite attribute in cookies helps prevent CSRF by restricting when cookies are sent. By setting SameSite=Strict or SameSite=Lax, you can control how cookies behave across sites:

• Strict: Cookies are only sent in requests from the same site. So, if a user clicks a link to your site from another domain, their browser won’t include these cookies. This is the most secure option, but it can sometimes be a bit restrictive since it might block legitimate interactions between sites.
  
• Lax: Allows cookies in top-level navigations while blocking them in subtle cross-site requests, like iframes or HTTP requests triggered by JavaScript. This is a balanced choice without being as restrictive as Strict.

Implementing SameSite is typically as simple as adding an attribute when setting cookies on your server.

This is how you would do it in an Express app with Node.js:

	
res.cookie('sessionId', 'your-session-id', {
  httpOnly: true,
  secure: true,
  sameSite: 'Strict', // or 'Lax' based on your requirement
});
	

Keep in mind that while SameSite is a great tool for CSRF protection, it’s not a complete solution on its own. It works best when paired with other security measures, like anti-CSRF tokens or CAPTCHAs. Also, some older browsers don’t support SameSite, so you’ll want to consider your user base when implementing it.

Require user re-authentication (CAPTCHA, passwords)

For sensitive actions like changing account settings, requiring a user to solve a CAPTCHA or re-enter their password adds an extra security layer against CSRF attacks. This ensures that a legitimate user is acting. 

If you’re using WorkOS, you can implement MFA prompts when users attempt sensitive actions like account changes or financial transactions.

CSRF vs. XSS: What’s the difference?

Both CSRF and XSS attacks are dangerous, but they target different vulnerabilities:

• CSRF manipulates user actions: It tricks users into performing unintended actions on websites where they’re already logged in, like changing account settings or making purchases without realizing it.
• XSS injects malicious scripts into web pages: Attackers use XSS to inject harmful code directly into a website. When users visit the page, their browser runs the malicious script, often allowing attackers to steal data like cookies or session tokens.

The attack vector is also different:

• CSRF attacks typically exploit GET requests: They are less likely to be blocked by browsers. The attacker crafts a malicious link or form that targets a vulnerable endpoint on the trusted site, causing the user's browser to execute the request without their knowledge or consent.
• XSS attacks can be executed through various means, including:
  • Reflected XSS: Injecting malicious script into the URL or query parameters.
  • Stored XSS: Injecting malicious script into the application's database and later retrieved and executed.
  • DOM-based XSS: Exploiting vulnerabilities in the Document Object Model (DOM) to inject malicious script.

Why CSRF attacks are dangerous for web applications

The consequences of CSRF attacks can be severe. If an attacker successfully forges a request, they could make changes to account settings, like updating email addresses or changing passwords, without the user’s knowledge. In more serious cases, attackers can initiate money transfers or other financial transactions from the user’s account. If the victim is an administrative account, CSRF can compromise the entire web application.

This kind of unauthorized access can lead to data breaches, exposing sensitive information, or result in financial loss for both the user and the application. The impact can be especially damaging for businesses that handle user data or online payments, eroding trust and causing reputational damage.

Because of these risks, it’s essential to use preventive measures like anti-CSRF tokens, as well as secure cookie settings (e.g., SameSite attributes). These measures add extra layers of validation to ensure that requests are made intentionally by users, not by malicious actors.

Conclusion

Understanding CSRF attacks is the first step. The next one is to prevent them with WorkOS's authentication and verification tools.

With seamless support for a wide range of authentication methods like Single Sign-On (SSO), multi-factor authentication (MFA), and other user management options, WorkOS covers all your bases, allowing you to focus on what matters most: building your core business features.

‍Start building with WorkOS.