Cross-Site Request Forgery (CSRF) Interview Questions and Answers

Learn Cross-Site Request Forgery (CSRF) with interview questions, Mermaid diagrams, Spring Security examples, prevention techniques, and enterprise security best practices.

Cross-Site Request Forgery (CSRF) - Interview Questions & Answers

Cross-Site Request Forgery (CSRF) is one of the most common web application vulnerabilities listed in the OWASP Top 10.

A CSRF attack tricks an authenticated user into performing an unwanted action on a trusted application without the user's knowledge.

Unlike SQL Injection or XSS, a CSRF attack does not steal credentials. Instead, it abuses the user's existing authenticated session.

Q1. What is CSRF?

Answer

Cross-Site Request Forgery (CSRF) is an attack where a malicious website causes a victim's browser to send an authenticated request to another trusted website.

Since the browser automatically includes cookies, the target application may believe the request came from the legitimate user.

CSRF Overview

flowchart LR

User --> TrustedWebsite

User --> MaliciousWebsite

MaliciousWebsite --> HiddenRequest

HiddenRequest --> TrustedWebsite

Example

A logged-in banking user visits a malicious website that silently submits a money transfer request.

Q2. How does a CSRF attack work?

Answer

A typical CSRF attack follows these steps:

User logs in to a trusted website.
Browser stores the session cookie.
User visits a malicious website.
The malicious website sends a hidden request.
Browser automatically includes the session cookie.
Server processes the request as if it came from the user.

Attack Flow

sequenceDiagram
participant User
participant Browser
participant Bank
participant MaliciousSite
User->>Bank: Login
Bank-->>Browser: Session Cookie
User->>MaliciousSite: Visit Website
MaliciousSite->>Browser: Hidden Form
Browser->>Bank: Authenticated Request + Cookie
Bank-->>Browser: Request Processed

Q3. Why is CSRF possible?

Answer

CSRF succeeds because browsers automatically send cookies with requests to the target website.

The server sees:

Valid session cookie
Authenticated user

But it cannot determine whether the request was intentionally initiated by the user.

Browser Behavior

flowchart TD

Browser --> SessionCookie["Session Cookie"]

SessionCookie["Session Cookie"] --> BankApplication["Bank Application"]

BankApplication["Bank Application"] --> AuthenticatedRequest["Authenticated Request"]

Q4. Which applications are vulnerable to CSRF?

Answer

Applications using cookie-based authentication are vulnerable.

Examples:

Banking Applications
E-commerce Websites
Healthcare Portals
Enterprise Portals
Admin Dashboards

REST APIs using Bearer JWT tokens in the Authorization header are generally not vulnerable to classic CSRF, because browsers do not automatically attach those headers.

Vulnerable Architecture

flowchart LR

Browser --> Cookie

Cookie --> SpringBootApplication["Spring Boot Application"]

Q5. What is a CSRF Token?

Answer

A CSRF Token is a random, unpredictable value generated by the server and associated with the user's session.

The client must send this token with every state-changing request.

The server validates the token before processing the request.

CSRF Token Validation

flowchart TD

ClientRequest["Client Request"] --> CsrfToken["CSRF Token"]

CsrfToken["CSRF Token"] --> SpringSecurity["Spring Security"]

SpringSecurity["Spring Security"] --> Valid?

Valid? --> Yes

Yes --> ProcessRequest["Process Request"]

Valid? --> No

No --> 403Forbidden["403 Forbidden"]

Q6. How does Spring Security protect against CSRF?

Answer

Spring Security enables CSRF protection by default for traditional web applications using session-based authentication.

It:

Generates a CSRF token
Stores the token
Validates every state-changing request
Rejects invalid requests

Spring Security Flow

flowchart LR

Browser --> SpringSecurity["Spring Security"]

SpringSecurity["Spring Security"] --> GenerateCsrfToken["Generate CSRF Token"]

GenerateCsrfToken["Generate CSRF Token"] --> ValidateRequest["Validate Request"]

ValidateRequest["Validate Request"] --> Application

Interview Tip

For stateless REST APIs secured with JWT Bearer tokens, CSRF protection is often disabled because cookies are not used for authentication.

Q7. How can CSRF attacks be prevented?

Answer

Common prevention techniques include:

CSRF Tokens
SameSite Cookies
Secure Cookies
HttpOnly Cookies
Origin Validation
Referer Validation
Re-authentication for critical actions

Prevention Layers

mindmap
  root((CSRF Protection))
    CSRF Token
    SameSite Cookies
    Origin Validation
    Referer Validation
    Secure Cookies
    HttpOnly Cookies

Q8. What is the difference between CSRF and XSS?

Answer

CSRF	XSS
Exploits authenticated user	Injects malicious JavaScript
Uses existing session	Executes attacker-controlled scripts
Targets server actions	Targets browser execution
Requires authenticated session	May not require authentication

Comparison

flowchart TD

CSRF --> AuthenticatedRequest["Authenticated Request"]

XSS --> MaliciousJavascript["Malicious JavaScript"]

Interview Tip

An XSS vulnerability can sometimes be used to bypass CSRF protections by stealing or manipulating CSRF tokens, making it important to defend against both.

Q9. What are common CSRF implementation mistakes?

Answer

Common mistakes include:

Disabling CSRF without understanding the impact
Missing CSRF token validation
Using predictable tokens
Missing SameSite cookie configuration
Trusting hidden form fields alone
Not validating Origin or Referer headers
Ignoring sensitive POST, PUT, PATCH, and DELETE requests

Wrong Design

Authenticated User

↓

POST Request

↓

No Validation ❌

Correct Design

Authenticated User

↓

CSRF Token

↓

Token Validation

↓

Process Request ✅

Q10. What are the enterprise best practices for CSRF protection?

Answer

Follow these best practices:

Enable CSRF protection for session-based applications.
Generate cryptographically secure CSRF tokens.
Validate every state-changing request.
Configure SameSite cookies appropriately.
Use Secure and HttpOnly cookies.
Validate Origin and Referer headers when applicable.
Require re-authentication for critical operations.
Use HTTPS everywhere.
Monitor suspicious request patterns.
Follow OWASP CSRF Prevention guidance.

Enterprise CSRF Protection

flowchart TD

User --> Browser

Browser --> SpringSecurity["Spring Security"]

SpringSecurity["Spring Security"] --> CsrfFilter["CSRF Filter"]

CsrfFilter["CSRF Filter"] --> Application

Application --> Database

Secure Request Pipeline

flowchart LR

UserRequest["User Request"] --> SessionCookieCsrfToken["Session Cookie → CSRF Token → Spring Security → Business Logic"]

CSRF Prevention Checklist

mindmap
  root((Prevent CSRF))
    CSRF Tokens
    SameSite Cookies
    Secure Cookies
    HttpOnly Cookies
    HTTPS
    Origin Validation
    Referer Validation
    Spring Security

Senior Interview Tip

CSRF protection depends on the authentication mechanism:

Session Cookie Authentication → Enable CSRF protection.
JWT Bearer Authentication (Authorization Header) → Classic CSRF protection is generally not required because browsers do not automatically send the token.

A production-ready enterprise architecture should combine:

Spring Security CSRF Protection
SameSite Cookies
HTTPS
MFA
Content Security Policy (CSP)
Secure Session Management
WAF
OAuth2/OpenID Connect
Zero Trust Architecture

Quick Revision

CSRF tricks authenticated users into performing unintended actions.
It primarily affects cookie-based authentication.
Browsers automatically send cookies, enabling the attack.
Spring Security enables CSRF protection by default for web applications.
Use unpredictable CSRF tokens for state-changing requests.
Configure SameSite, Secure, and HttpOnly cookies.
Validate Origin and Referer headers where appropriate.
JWT Bearer token APIs are generally not vulnerable to classic CSRF.
Always use HTTPS.
Combine CSRF protection with secure session management and OWASP best practices.