Cross-Site Request Forgery (CSRF) is an attack that tricks a user into performing an unwanted action on a web application where they are currently authenticated. This type of attack exploits the trust a web application has in an authenticated user.
TL;DR: A CSRF attack forces a logged-in user to unknowingly submit a malicious request to a website, like changing their email address or transferring funds without their consent. Think of it as a threat actor hijacking your authenticated session to do things on your behalf.
Cross-Site Request Forgery, often called CSRF (pronounced "sea-surf") or XSRF, is one of the more sneaky cybersecurity threats out there. It’s an attack that forces an end user to execute unwanted actions on a web application in which they’re currently logged in. The whole point of a CSRF attack is to exploit the trust that a web application has in a user.
So, how does this actually work? Let's break it down.
Imagine you're logged into your online banking website. Without logging out, you open a new tab and visit another website—maybe one sent to you in a phishing email or a shady forum. This other site could have hidden code that automatically sends a request back to your banking site. Since you're still authenticated with your bank, the bank's server sees this request as legitimate and processes it. Bam! You might have just unknowingly transferred money or changed your account details.
For a CSRF attack to be successful, a few things need to line up:
Relevant action: The attacker needs a target action that they can trigger. This could be anything from changing a password, making a purchase, or sending a message. The more privileged the user, the more damage can be done.
Cookie-based session handling: The application must rely solely on session cookies to identify the user who is making the requests. The browser automatically includes these cookies with every request to the site.
No unpredictable parameters: The malicious request shouldn't require any parameters that the attacker can't determine or guess. If the request needs a secret token, for example, the attack will likely fail.
A common delivery method for a CSRF attack is through a malicious link or a specially crafted HTML image tag. For example, an attacker could embed an image tag in an email that points to a URL that performs an action, like:
When your browser tries to load this "image," it actually sends a request to your bank to transfer $1,000. Because you're already logged in, the bank processes it. Ouch.
Our team examined a vulnerability in ConnectWise Control, originally reported by Bishop Fox (assigned CVE-2019-16513). In this case, the application lacked CSRF protection, meaning that if an authenticated user visited a malicious third-party website, a hidden script could send unauthorized API requests—such as disabling security alerts—without the user's knowledge or consent.
Once validated that after patches were applied and CORS policies tightened, the specific CSRF proof-of-concept no longer functioned. However, the broader lesson remains: even when other defenses are in place, the absence of CSRF tokens can still open the door to stealthy, unauthorized actions on a user's behalf—underscoring why CSRF protections are essential for modifying data on behalf of authenticated users
Fortunately, there are solid ways to defend against these kinds of cybersecurity threats. Most modern web development frameworks have built-in protections, but it's good to know what they are.
Anti-CSRF tokens: The most common and robust defense is the use of anti-CSRF tokens. The application generates a unique, unpredictable token for each user session and embeds it in hidden fields within forms. When a user submits the form, the token is sent back to the server, which validates it. Since an attacker can't guess this token, they can't forge a valid request. As ≈, a leading nonprofit focused on software security, explains, this method is highly effective.
SameSite cookies: This is a browser-level security mechanism that developers can use to control whether cookies are sent with cross-site requests. By setting a cookie's SameSite attribute to Strict or Lax, a developer can prevent the browser from sending the session cookie with a cross-site request, which neuters the CSRF attack. You can find more technical details about this method in resources like the CISA (Cybersecurity & Infrastructure Security Agency) security tips.
User interaction: Requiring user interaction for sensitive actions—like re-entering a password or solving a CAPTCHA before changing an email address—can also prevent CSRF. It ensures the legitimate user is present and consenting to the action.
Cross-Site Request Forgery (CSRF) is an attack that tricks authenticated users into performing actions they didn't intend to. This cybersecurity threat works by exploiting the trust an application has in a logged-in user's browser. Successful CSRF attacks can lead to unauthorized fund transfers, data theft, or complete account takeovers.The best defenses include using anti-CSRF tokens and implementing SameSite cookies to validate that requests are coming from the original application, not a malicious third-party site.
