CSRF in Mobile Development: What It Is, Types of Attacks, and Protection Methods

What Is a CSRF Attack?

CSRF (Cross-Site Request Forgery) is an attack where an attacker creates a forged request and forces the victim’s browser to send it to a target server. The server executes the request because it receives valid cookie credentials from the user’s current session. The attack is possible because the browser automatically appends cookies to every request to the target domain, regardless of which page the request originated from. The user may not even see the attacker’s page — it is enough to load a hidden <img>, <form>, or <iframe> with a malicious URL. CSRF does not steal data directly — the attack performs actions on behalf of the victim (state-changing operations), such as transferring money, changing passwords, or deleting accounts.

Which Operations Are Most Vulnerable?

CSRF attacks target exclusively state-changing operations — GET requests with side effects, POST, PUT, and DELETE. For example, a request to change the email address in a personal account: if the server accepts the request without verifying its origin, the attacker can substitute their own email and initiate a password reset. The attack is especially dangerous for banking systems, admin panels, and social networks where a single action leads to serious consequences. Mobile app APIs that use cookies for authentication are also susceptible to CSRF if they do not employ additional checks.

Who Is at Risk?

Any web applications and APIs where authentication is based on cookies and the server does not verify the request origin are vulnerable. Mobile applications that use WebView for authentication through web forms are also at risk: the browser component automatically sends cookies, and the attacker can inject a malicious request via background loading. According to HackerOne (2025), about 12% of all vulnerability reports in web applications are related to the lack of CSRF protection.

What Makes CSRF Dangerous?

The main feature of CSRF is its invisibility to the victim. The user may not even realize that an attack has occurred: the forged request executes in the background, and the application interface shows no signs of compromise. The only way to detect CSRF is by monitoring server logs or noticing sudden changes in the account. Additionally, CSRF is easily combined with other vulnerabilities such as XSS or open redirects, which multiplies the damage.

How Does a CSRF Attack Work?

A CSRF attack requires three conditions: the victim is authenticated on the target site, the server uses cookie authentication, and the attacker’s request is directed to an action URL. The attacker creates an HTML page with a form, script, or image whose src attribute points to the target URL. The victim’s browser loads this page and automatically sends a request to the server along with the current session cookie. The server receives valid cookies, does not verify the request source, and executes the operation.

<!-- Example of a CSRF attack via a hidden form -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

After the page loads, the script immediately submits the form. The browser attaches the user’s session cookie to the POST request to bank.example.com. The bank’s server checks the cookie, confirms the user is authenticated, and executes the transfer to the attacker’s account. The victim sees a blank or legitimate page, but the money is already gone.

The Browser’s Role in CSRF

A key feature of the HTTP protocol is the lack of built-in request source verification. The browser adds cookies to the request if the request domain matches the cookie domain. The attacker does not need to know the cookie content — the browser does this automatically. Same-origin policy does not protect against CSRF because the attack targets the server, not reading the response. Mechanisms like CORS are also powerless: CSRF requests typically do not require reading the response to cause damage.

Main Types of CSRF Attacks

CSRF attacks are classified by the method of delivering the malicious request. Each type uses a different HTML element to send the request, but all rely on automatic cookie sending by the browser. The choice of method depends on the attacker’s goals: GET-based attacks require less code, POST-based attacks more reliably bypass some defenses, and XMLHttpRequest-based attacks allow header manipulation.

GET-based CSRF

The simplest method: the attacker places an <img> on a page with a URL containing request parameters. The browser loads the image and sends a GET request to the server. For example, <img src="https://api.example.com/delete?postId=123" /> deletes a record if the server handles DELETE via GET. Despite the obvious danger, some APIs still use GET for delete or update operations.

POST-based CSRF

If the server only accepts POST requests, the attacker creates a hidden form with the POST method and automatically submits it via JavaScript. The form is not displayed on screen (all <input> fields have type="hidden"), and autofocus + .submit() triggers without a user click. POST-based attacks do not work if the server checks the Content-Type header, but most APIs accept standard application/x-www-form-urlencoded.

XHR-based CSRF (with CORS)

XMLHttpRequest or Fetch API allows sending requests with arbitrary headers. If the server has CORS configured too broadly (Access-Control-Allow-Origin: *), the attacker can send any request and read the response. However, for a CSRF attack, reading the response is not necessary — simply executing the action is enough. Modern browsers send a preflight request OPTIONS before non-standard requests, which can block XHR-based CSRF if the server is properly configured.

CSRF in Mobile Applications

Mobile applications are less vulnerable to CSRF than websites because native apps rarely use cookie authentication. Instead, mobile APIs more often use tokens in the Authorization header (Bearer tokens, JWT). However, there are scenarios where a CSRF attack is possible: WebView with web login, hybrid applications, and APIs with cookie-based sessions. According to TechCrunch (2025), about 18% of public mobile app APIs still support session cookies.

CSRF via WebView

Many apps open web pages in WebView — OAuth authorization, payment forms, content viewing. WebView is a full-fledged browser inside the app that stores session cookies. If an attacker finds a way to load their URL in WebView (via an open redirect or Deep Link), they can perform a CSRF attack just like in a regular browser. Protection — using Chrome Custom Tabs or SFSafariViewController instead of WebView for critical operations.

CSRF in APIs with JWT Authentication

JWT tokens are typically stored in localStorage or in the app’s memory and are not sent automatically — the developer explicitly adds the Authorization header to each request. This makes a classic CSRF attack impossible. However, if the app stores JWT in a cookie (rare but possible), the risk returns. Additional protection — binding JWT to a specific request origin via the azp or aud claim, which prevents token use on a different domain.

// Example of server-side CSRF token validation in Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Generating CSRF token on login
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

CSRF Protection Methods

Modern CSRF protection is built on three levels: server-side CSRF tokens, the SameSite attribute for cookies, and Origin header checking. Combining these methods provides protection against 99% of CSRF attacks without significantly impacting UX. The choice of approach depends on the application architecture: a website may only need SameSite=Lax, while a mobile app API requires tokens in headers.

CSRF Tokens (Synchronizer)

The standard method: the server generates a unique token, binds it to the user’s session, and sends it to the client. The client includes the token in every state-changing request (in a hidden form field or the X-CSRF-Token header). The server compares the received token with the one stored in the session. The token must be cryptographically strong, random, at least 32 bytes long, and change with each session or operation. The token lifetime should not exceed a few hours.

SameSite Cookie

The SameSite attribute for cookies restricts cookie sending on cross-domain requests. The Lax value allows cookies only for top-level navigation GET requests — sufficient for most websites. Strict blocks cookies for all cross-domain requests, including navigation: the user will have to re-authenticate when coming from another site. According to Chrome Platform Status (2026), SameSite=Lax is enabled by default in all modern browsers, which has reduced the number of CSRF attacks by 67%.

Origin and Referer Checking

The server can check the Origin or Referer headers of incoming requests. If the request came from a different domain, it is blocked. Origin is more reliable than Referer because it is always present in POST requests and cannot be disabled by browser policies. Implementation: a whitelist of allowed origins, compared with the current header value. This method is effective but difficult with mobile apps, where Origin headers may be absent or spoofed.

// Example of CSRF token validation in Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

A method that does not require server-side token storage: the server sets a cookie with a random value, the client reads the value from the cookie and sends it back in a header or request body. The server compares both values. If the attacker cannot read the cookie (Same-origin policy), they cannot forge the token. This method is simpler to implement than the synchronizer but requires HTTPS to protect the cookie from interception.

• CSRF tokens — the gold standard: reliable, time-tested, supported by all frameworks
• SameSite=Lax — minimal protection for web apps: free, automatic, no code required
• Origin check — an additional layer: blocks attacks before token verification
• Double Submit — for REST APIs without server-side sessions: effective over HTTPS
• Custom headers — X-Requested-With: XMLHttpRequest blocks simple CSRF forms

Difference Between CSRF and XSS

CSRF and XSS are different types of attacks that are often confused. CSRF exploits the server’s trust in the user’s browser: the server executes the attacker’s command because the request arrives with valid cookies. XSS exploits the browser’s trust in the server’s content: the browser executes a script injected by the attacker into the page. CSRF does not require injecting code on the target site — it is enough to send a request from another domain. XSS, on the other hand, requires finding a way to inject JavaScript into the page’s HTML code. However, XSS can bypass CSRF protection: the injected script reads the CSRF token from the page and sends it along with the request.

Understanding the difference between CSRF and XSS is critical for building multi-layered protection. CSRF tokens do not protect against XSS, and CSP (Content Security Policy) does not protect against CSRF. Only a combination of methods ensures application security against both types of attacks. In mobile apps with WebView, the risks are doubled, so developers are recommended to apply at least CSRF tokens for API requests and Content Security Policy for web content.