DEV Community: Aswani Nayak

Enabling CSRF in a JWT-Based React + Spring Boot Application (Enterprise-Ready Approach)

Aswani Nayak — Wed, 27 May 2026 13:52:27 +0000

Modern applications often use:
• React SPA (Single Page Application)
• Spring Boot backend
• JWT-based authentication
• Stateless REST APIs
In this architecture, it’s common to disable CSRF:
Code
.csrf(AbstractHttpConfigurer::disable)
However, many enterprise security teams and tools (e.g., GitHub CodeQL) flag this as a high-severity issue.
This blog explains:
• ✅ Why CSRF is flagged
• ✅ Whether JWT APIs need CSRF
• ✅ How to enable CSRF without breaking your SPA
• ✅ A production-ready implementation

1️⃣ Understanding the Problem
What is CSRF?
CSRF (Cross-Site Request Forgery) is an attack where a malicious website tricks a browser into making an authenticated request to another site.
CSRF attacks rely on:
• Automatic cookie sending by the browser
• Session-based authentication
Spring Security enables CSRF by default for this reason.

Why JWT APIs Typically Disable CSRF
In a JWT-based system:
• Authentication is done via:
• Authorization: Bearer
• Browsers do NOT automatically attach Authorization headers.
• No session cookies are involved.
• The API is stateless.
Therefore, CSRF protection is not strictly required.
However...

Why Security Teams Still Want It Enabled
Enterprise AppSec teams often require:
• Defense-in-depth
• Uniform policy enforcement
• Future-proof protection (in case cookies are introduced later)
• Clean security scans without exceptions
Instead of disabling CSRF, we can implement it correctly for SPA.

2️⃣ Enterprise-Ready Solution
We will:
• ✅ Keep JWT authentication
• ✅ Keep backend stateless
• ✅ Enable CSRF
• ✅ Make it work with React SPA
• ✅ Pass security review
The key is:
Code
CookieCsrfTokenRepository

3️⃣ Spring Boot Implementation
✅ Step 1: Security Configuration
Code

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    public SecurityConfig(JwtAuthenticationFilter jwtAuthenticationFilter) {
        this.jwtAuthenticationFilter = jwtAuthenticationFilter;
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {

        http
            // ✅ Enable CSRF with Cookie repository (SPA-friendly)
            .csrf(csrf -> csrf
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
            )

            // ✅ Keep application stateless
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            )

            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/auth/**").permitAll()
                .anyRequest().authenticated()
            )

            // ✅ Add JWT filter
            .addFilterBefore(jwtAuthenticationFilter,
                    UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }
}

✅ What This Does
Spring Security will:

Generate a CSRF token
Send it in a cookie named: XSRF-TOKEN
Expect the frontend to send it back in header: X-XSRF-TOKEN This pattern is SPA-friendly and secure.

4️⃣ React Implementation
✅ Step 1: Enable Credentials
When using cookies, you must enable credentials:
Code

const api = axios.create({
  baseURL: "http://localhost:8080",
  withCredentials: true
});

✅ Step 2: Read CSRF Cookie
Helper function:
Code

function getCookie(name) {
  const value = `; ${document.cookie}`;
  const parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
}

✅ Step 3: Axios Interceptor
Code

api.interceptors.request.use((config) => {

  const jwt = localStorage.getItem("jwt");
  const csrfToken = getCookie("XSRF-TOKEN");

  if (jwt) {
    config.headers.Authorization = `Bearer ${jwt}`;
  }

  if (csrfToken) {
    config.headers["X-XSRF-TOKEN"] = csrfToken;
  }

  return config;
});

Now every request sends:
• ✅ JWT token
• ✅ CSRF token

5️⃣ CORS Configuration (Critical)
When using cookies, you must allow credentials.
Code

@Bean
public CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration configuration = new CorsConfiguration();
    configuration.setAllowedOrigins(List.of("http://localhost:3000"));
    configuration.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    configuration.setAllowedHeaders(
        List.of("Authorization", "Content-Type", "X-XSRF-TOKEN")
    );
    configuration.setAllowCredentials(true);

    UrlBasedCorsConfigurationSource source =
            new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", configuration);
    return source;
}

And enable CORS:
Code
http.cors(Customizer.withDefaults());

6️⃣ Request Flow Explained
✅ Initial Request
• Backend generates CSRF token
• Sends XSRF-TOKEN cookie
✅ API Call
React sends:
Authorization: Bearer
X-XSRF-TOKEN:
✅ Spring Validates
• JWT signature
• CSRF token match
If both valid → request succeeds.

7️⃣ Architecture Summary

8️⃣ Why This Is a Strong Design
Even though JWT Authorization header authentication does not require CSRF, enabling it provides:
• Defense-in-depth
• Protection against future cookie-based changes
• Compliance with security standards
• Cleaner audit results
This approach balances:
✅ Security
✅ Architecture purity
✅ Enterprise compliance

9️⃣ Final Thoughts
If you are building:
• React SPA
• Spring Boot backend
• JWT authentication
And your security team requires CSRF to be enabled:
✅ Use CookieCsrfTokenRepository
✅ Send CSRF token via header
✅ Keep the application stateless
This gives you:
• Modern architecture
• Strong security posture
• Enterprise-ready implementation

Storing Personal Information in React: sessionStorage vs Context API

Aswani Nayak — Mon, 18 May 2026 02:25:35 +0000

When building React applications, developers often need to handle personal information such as names, emails, profile data, or authentication details.
A common question arises:
Should I store personal information in sessionStorage or use React’s Context API?
The answer depends heavily on security, persistence needs, and application design. In this post, we’ll break down the differences, risks, and best practices.

Understanding the Two Options
1️⃣ What Is sessionStorage?
sessionStorage is a browser-based storage mechanism that:
• Stores data per tab
• Persists across page refreshes
• Clears when the tab is closed
• Is accessible via JavaScript
Example:
Code

// Store data
sessionStorage.setItem("userEmail", "user@example.com");

// Retrieve data
const email = sessionStorage.getItem("userEmail");

2️⃣ What Is React Context API?
The Context API is a React feature that allows you to:
• Share state across components
• Store data in memory
• Avoid prop drilling
• Reset data on page refresh
Example:
Code

import { createContext, useContext, useState } from "react";

const UserContext = createContext();

export const UserProvider = ({ children }) => {
  const [user, setUser] = useState(null);

  return (
    <UserContext.Provider value={{ user, setUser }}>
      {children}
    </UserContext.Provider>
  );
};

export const useUser = () => useContext(UserContext);

Key Differences

Security Considerations (Critical for Personal Info)
When storing personal information (PII), security should be your top priority.
🔴 Risks of Using sessionStorage
• Accessible via browser DevTools
• Accessible to any script running on the page
• Vulnerable to Cross-Site Scripting (XSS)
• Persists after refresh (increasing exposure window)
If your app suffers from an XSS vulnerability, malicious code could easily run:
Code
sessionStorage.getItem("userSSN");
That’s a serious risk.

🟢 Why Context API Is Safer
Context data:
• Lives only in memory
• Disappears on refresh
• Is scoped within your React app
• Is not automatically accessible globally
However, note:
Context is still vulnerable to XSS if your app is compromised.
No client-side storage is 100% secure.

When Should You Use Each?
✅ Use Context API When:
• Handling sensitive personal information
• Data does not need to survive page refresh
• You want better encapsulation
• Managing user session state
Examples:
• User profile details
• Temporary form data
• Authenticated user state

✅ Use sessionStorage When:
• You need data to persist across refresh
• The data is low sensitivity
• UX depends on temporary persistence
Examples:
• Wizard step progress
• Non-sensitive UI preferences
• Temporary search filters

What You Should NEVER Store in sessionStorage
Avoid storing:
• Passwords
• Social Security Numbers
• Credit card numbers
• Medical data
• Raw authentication tokens
• Sensitive PII
If the data would be catastrophic if exposed — don’t store it client-side.

The Best Practice Architecture
For handling personal information securely in modern React apps:
✅ Recommended Approach
• Store authentication tokens in HTTP-only secure cookies
• Store user profile data in React Context (memory)
• Keep highly sensitive data on the backend only
Architecture flow:
Backend
↓
HTTP-only cookie (auth token)
↓
React Context (user state in memory)
Why this works:
• HTTP-only cookies cannot be accessed via JavaScript
• Context keeps sensitive UI data ephemeral
• Exposure window is minimized

Final Recommendation
If you're choosing between sessionStorage and Context API for personal information:
✅ Use React Context for sensitive data
⚠️ Use sessionStorage only for low-risk persistence needs
And remember:
The most secure data is the data you never store on the client.