Skip to content

CSRF: Definition and Applications

TL;DR:

CSRF (Cross-Site Request Forgery) — attack where the adversary makes the victim's browser send a request to another site with the victim's credentials (cookies). Defence: CSRF tokens in forms, SameSite=Lax/Strict cookies, double-submit pattern, referer validation.

Check your site's security →

What is CSRF

CSRF (Cross-Site Request Forgery) — attack where the adversary makes the victim's browser send a request to another site with the victim's credentials (cookies). Defence: CSRF tokens in forms, SameSite=Lax/Strict cookies, double-submit pattern, referer validation.

Understanding CSRF Tokens: Mechanism and Implementation

Cross-Site Request Forgery (CSRF) tokens are unique, unpredictable values generated by the server and included in requests to ensure that the request comes from a legitimate user. The primary purpose of CSRF tokens is to prevent unauthorized commands from being transmitted from a user that the web application trusts.

When a user accesses a web application, the server generates a CSRF token and embeds it in forms and requests. This token is typically stored in the user's session and is validated on form submission. If the token in the request does not match the token stored on the server, the request is rejected, thus mitigating the risk of CSRF attacks.

To implement CSRF tokens, follow these steps:

  • Generate a Token: When a user session is created, generate a CSRF token using a secure random function.
  • Embed the Token: Include the CSRF token in all HTML forms as a hidden input field:
  • <input type='hidden' name='csrf_token' value='[GENERATED_TOKEN]'>
  • Validate the Token: On form submission, check if the submitted token matches the one stored in the user's session. If not, invalidate the request.

By implementing CSRF tokens, web applications can significantly reduce the risk of CSRF attacks, ensuring that all requests are authenticated and authorized.

Common CSRF Attack Scenarios and Prevention Techniques

CSRF attacks can occur in various contexts, often exploiting the trust that a web application has in a user's browser. Understanding common attack scenarios helps in crafting effective defenses.

Here are some common scenarios:

  • Account Settings Change: An attacker can create a malicious page with a form that submits a request to change a user's email address or password on a target application. If the user is logged in, their credentials (cookies) will be sent along with the request.
  • Fund Transfer: In banking applications, an attacker can trick a logged-in user into transferring funds to the attacker's account by submitting a forged request.
  • Data Deletion: An attacker can use CSRF to delete sensitive data by crafting a request to the delete endpoint of a web application while the user is authenticated.

To prevent CSRF attacks, consider the following techniques:

  • CSRF Tokens: As mentioned previously, using CSRF tokens is a primary defense mechanism.
  • SameSite Cookies: Setting the SameSite attribute on cookies to Lax or Strict limits when cookies are sent with cross-origin requests.
  • Referer Header Validation: Check the Referer header to ensure that requests are coming from trusted origins.

By understanding potential attack scenarios and implementing robust prevention techniques, web applications can enhance their security posture against CSRF vulnerabilities.

Testing for CSRF Vulnerabilities: Tools and Techniques

Testing for CSRF vulnerabilities is essential for ensuring the security of web applications. There are several tools and techniques that security professionals can use to identify potential CSRF weaknesses.

1. Burp Suite: This popular web application security testing tool includes features specifically designed for testing CSRF vulnerabilities. Use the Intruder feature to automate requests with and without CSRF tokens to observe the application's behavior.

2. OWASP ZAP: The OWASP Zed Attack Proxy (ZAP) can be used to scan web applications for CSRF vulnerabilities. Configure ZAP to intercept requests and analyze whether CSRF tokens are being used effectively.

3. Manual Testing: Perform manual testing by crafting malicious requests. For example, create a simple HTML form that submits to a target URL:

<form action='https://target-application.com/change-email' method='POST'><input type='hidden' name='email' value='attacker@example.com'><input type='submit' value='Submit'></form>

4. Browser Developer Tools: Use browser developer tools to inspect requests and responses. Check if CSRF tokens are present in forms and whether they are validated on the server side.

By employing these tools and techniques, security professionals can effectively identify and mitigate CSRF vulnerabilities, ensuring the integrity of web applications.

HeadersCSP, HSTS, X-Frame-Options, etc.
SSL/TLSEncryption and certificate
ConfigurationServer settings and leaks
Grade A-FOverall security score

Why teams trust us

OWASP
guidelines
15+
security headers
<2s
result
A–F
security grade

How it works

1

Enter site URL

2

Security headers analyzed

3

Get grade A–F

What Does the Security Analysis Check?

The tool checks HTTP security headers, SSL/TLS configuration, server info leaks, and protection against common attacks (XSS, clickjacking, MIME sniffing). A grade fromA to F shows overall security level.

Header Analysis

Checking Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and more.

SSL Check

TLS version, certificate expiry, chain of trust, HSTS support.

Leak Detection

Finding exposed server versions, debug modes, open configs, and directories.

Report with Recommendations

Detailed report explaining each issue with specific steps to fix it.

Who uses this

Security teams

HTTP header audit

DevOps

config verification

Developers

CSP & HSTS setup

Auditors

compliance checks

Common Mistakes

Missing Content-Security-PolicyCSP is the primary XSS defense. Without it, script injection is much easier.
Missing HSTS headerWithout HSTS, HTTPS-to-HTTP downgrade attacks are possible. Enable Strict-Transport-Security.
Server header exposes versionServer: Apache/2.4.52 helps attackers find exploits. Hide the version.
X-Frame-Options not setSite can be embedded in iframe for clickjacking. Set DENY or SAMEORIGIN.
Missing X-Content-Type-OptionsWithout nosniff, browsers may misinterpret file types (MIME sniffing).

Best Practices

Start with basic headersMinimum: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Takes 5 minutes.
Implement CSP graduallyStart with Content-Security-Policy-Report-Only, monitor violations, then enforce.
Hide server headersRemove Server, X-Powered-By, X-AspNet-Version from responses.
Configure Permissions-PolicyRestrict camera, microphone, geolocation access — only what is actually used.
Check after every deploySecurity headers can be overwritten during server configuration updates.

Get more with a free account

Security check history and HTTP security header monitoring.

Sign up free

Learn more

Frequently Asked Questions

Does this apply to my project?

See definition above. Most web projects with traffic > 100 RPS need it.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.