DEV Community: Aswani Nayak

Role-Based and Permission-Based Access Control in Spring Security

Aswani Nayak — Mon, 05 Oct 2026 19:21:38 +0000

Introduction

Once authentication is solid, the next question is inevitable: what is this user actually allowed to do? Authentication proves who you are; authorization decides what you can access. Conflating the two—or implementing authorization carelessly—is a common source of privilege-escalation bugs.

In my previous post, Building a Full Enterprise-Ready React + Spring Boot Auth Flow, I promised to expand on role-based access. This post delivers that: we'll cover both role-based access control (RBAC) and the more granular permission-based access control, how they differ, and how to implement each cleanly in Spring Security.

Roles vs. Permissions: What's the Difference?

These terms are often used interchangeably, but they model access at different levels of granularity.

Concept	Granularity	Example	Best For
Role	Coarse	`ROLE_ADMIN`, `ROLE_USER`	Broad user categories
Permission (authority)	Fine	`document:read`, `document:delete`	Specific actions on resources

A useful mental model:

Roles answer "what kind of user is this?"
Permissions answer "what specific action can this user perform?"

A role is typically a named bundle of permissions. For example, ROLE_EDITOR might group article:read, article:write, and article:publish. This indirection is powerful: you can change what an editor can do without touching every user—you just adjust the role's permission set.

A note on Spring's naming

In Spring Security, both roles and permissions are represented as GrantedAuthority objects. The only real distinction is a convention: roles are authorities prefixed with ROLE_. When you use helpers like hasRole("ADMIN"), Spring automatically prepends ROLE_, so it checks for the authority ROLE_ADMIN. When you use hasAuthority("document:read"), no prefix is added.

Modeling Roles and Permissions

A clean domain model separates users, roles, and permissions so the relationships are explicit.

@Entity
public class Permission {
    @Id @GeneratedValue
    private Long id;
    private String name; // e.g. "document:read"
}

@Entity
public class Role {
    @Id @GeneratedValue
    private Long id;
    private String name; // e.g. "ROLE_EDITOR"

    @ManyToMany(fetch = FetchType.EAGER)
    private Set<Permission> permissions = new HashSet<>();
}

@Entity
public class User {
    @Id @GeneratedValue
    private Long id;
    private String username;
    private String password;

    @ManyToMany(fetch = FetchType.EAGER)
    private Set<Role> roles = new HashSet<>();
}

This structure gives you a many-to-many relationship in both directions: users can have multiple roles, and roles can share permissions.

Mapping to Spring Security Authorities

Spring Security needs your user's roles and permissions expressed as GrantedAuthority objects. The key step is flattening both roles and their nested permissions into a single authority collection.

public class UserDetailsImpl implements UserDetails {

    private final User user;

    public UserDetailsImpl(User user) {
        this.user = user;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Set<GrantedAuthority> authorities = new HashSet<>();

        for (Role role : user.getRoles()) {
            // Add the role itself (e.g. ROLE_EDITOR)
            authorities.add(new SimpleGrantedAuthority(role.getName()));

            // Add each permission the role grants (e.g. article:write)
            for (Permission permission : role.getPermissions()) {
                authorities.add(new SimpleGrantedAuthority(permission.getName()));
            }
        }
        return authorities;
    }

    @Override
    public String getUsername() {
        return user.getUsername();
    }

    @Override
    public String getPassword() {
        return user.getPassword();
    }

    // Remaining UserDetails methods (account status flags) omitted for brevity
}

Design note: Flattening permissions into the authority set at load time means your authorization checks later are simple string comparisons—no lazy loading or extra queries during request handling.

Approach 1: URL-Based Authorization

The broadest form of access control is securing endpoints at the HTTP layer in your SecurityFilterChain.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            // Role-based: only admins can reach admin endpoints
            .requestMatchers("/api/admin/**").hasRole("ADMIN")

            // Permission-based: fine-grained control on a specific action
            .requestMatchers(HttpMethod.DELETE, "/api/documents/**")
                .hasAuthority("document:delete")

            // Multiple roles allowed
            .requestMatchers("/api/reports/**").hasAnyRole("ADMIN", "MANAGER")

            .anyRequest().authenticated());

    return http.build();
}

URL-based rules are great for broad strokes, but they live far from your business logic and can't easily express rules like "users can only edit their own documents." For that, we need method-level security.

Approach 2: Method-Level Authorization

Method security lets you place authorization rules directly on service or controller methods. First, enable it:

@Configuration
@EnableMethodSecurity // enables @PreAuthorize, @PostAuthorize, etc.
public class MethodSecurityConfig {
}

`@PreAuthorize` — check before the method runs

This is the most common and flexible annotation. It evaluates a SpEL expression before invocation.

@Service
public class DocumentService {

    // Role-based check
    @PreAuthorize("hasRole('ADMIN')")
    public void deleteAllDocuments() {
        // ...
    }

    // Permission-based check
    @PreAuthorize("hasAuthority('document:write')")
    public Document createDocument(DocumentRequest request) {
        // ...
    }

    // Combining checks
    @PreAuthorize("hasRole('MANAGER') and hasAuthority('report:export')")
    public byte[] exportReport(Long reportId) {
        // ...
    }
}

Using method arguments in expressions

The real power of @PreAuthorize is referencing method parameters, enabling ownership-style rules.

// Allow if the user has the permission AND owns the resource
@PreAuthorize("hasAuthority('document:edit') and #document.ownerId == authentication.principal.id")
public Document updateDocument(Document document) {
    // ...
}

`@PostAuthorize` — check after the method runs

Sometimes you can only decide once you've seen the result—for example, checking ownership of a fetched entity.

@PostAuthorize("returnObject.ownerId == authentication.principal.id")
public Document getDocument(Long id) {
    return documentRepository.findById(id).orElseThrow();
}

Caution: @PostAuthorize runs the method first and only then blocks the return value. Never use it for operations with side effects (like deletes)—the work is already done by the time authorization fails.

Approach 3: Custom Permission Logic

When expressions get complex or repetitive, extract the logic into a reusable bean and call it from SpEL.

@Component("documentSecurity")
public class DocumentSecurity {

    public boolean canEdit(Long documentId, Authentication authentication) {
        // Custom logic: ownership, shared access, org membership, etc.
        Long userId = ((UserDetailsImpl) authentication.getPrincipal()).getId();
        return documentRepository.isOwnerOrCollaborator(documentId, userId);
    }
}

Reference it in an annotation:

@PreAuthorize("@documentSecurity.canEdit(#id, authentication)")
public Document updateDocument(Long id, DocumentRequest request) {
    // ...
}

This keeps complex rules testable, reusable, and out of your annotations.

Connecting to the Frontend

Authorization must be enforced on the backend—the frontend check is purely for UX. Never rely on hiding a button as your security boundary; a determined user can still call the API directly.

That said, exposing the user's permissions to React lets you tailor the UI. Return authorities from an endpoint like /auth/me:

{
  "username": "jane",
  "roles": ["ROLE_EDITOR"],
  "permissions": ["article:read", "article:write", "article:publish"]
}

Then gate UI elements with a small helper:

import { useAuth } from "./AuthContext";

export function usePermission(permission) {
  const { user } = useAuth();
  return user?.permissions?.includes(permission) ?? false;
}

// Usage in a component
function PublishButton() {
  const canPublish = usePermission("article:publish");
  if (!canPublish) return null;
  return <button>Publish</button>;
}

Reminder: This only improves the experience. The backend @PreAuthorize check is what actually protects the action.

Common Pitfalls to Avoid

Pitfall	Consequence	Fix
Trusting frontend checks only	Trivial privilege escalation	Always enforce on the backend
Forgetting the `ROLE_` prefix	`hasRole` checks silently fail	Let Spring add the prefix; store authorities consistently
Using `@PostAuthorize` on side-effecting methods	Action runs before the check	Use `@PreAuthorize` for mutations
Hardcoding roles in many places	Brittle, hard to change	Model roles as bundles of permissions
Overly coarse roles	Can't express fine-grained rules	Add permission-level authorities
Not enabling method security	Annotations silently ignored	Add `@EnableMethodSecurity`

Bringing It Together

A robust authorization layer uses the right tool at each level:

URL-based rules for broad, endpoint-level gating.
Method-level @PreAuthorize for business-rule and ownership checks.
Custom security beans for complex, reusable logic.
Roles as bundles of permissions for maintainable, flexible access models.
Frontend checks for UX only, with the backend as the true boundary.

Roles give you convenient, coarse categories; permissions give you precise control. Most real applications benefit from using both together.

A Note on Verification

The code samples here are illustrative and follow common, modern Spring Security patterns. Because these APIs evolve across versions:

Confirm the method-security annotation setup for your version. @EnableMethodSecurity is the current approach, but older code may use @EnableGlobalMethodSecurity with different attributes.
Verify SpEL expression support and the exact principal type available in your authentication object.
Test both the allow and deny paths for every protected method—authorization bugs often hide in the cases you didn't test.

If you'd like, I can expand this into a focused follow-up on testing authorization rules or integrating an external identity provider (like Keycloak) for centralized RBAC. Let me know.

Building a Full Enterprise-Ready React + Spring Boot Auth Flow: An End-to-End Guide

Aswani Nayak — Fri, 21 Aug 2026 20:46:06 +0000

Introduction

Authentication is one of those things that looks simple in a tutorial and becomes surprisingly complex in production. Between token storage, CSRF protection, refresh flows, and protected routing, there are many places to get it wrong—and getting it wrong has real security consequences.

In two earlier posts, I covered pieces of this puzzle: Enabling CSRF in a JWT-Based React + Spring Boot Application and Storing Personal Information in React: sessionStorage vs Context API. This post ties those threads together into a complete, end-to-end authentication flow you can adapt for enterprise applications.

We'll walk through the full journey: login → token issuance → secure storage → protected routes → token refresh → logout.

Architecture Overview

Before the code, here's the high-level flow:

┌──────────────┐         ┌──────────────────┐
│    React     │         │   Spring Boot    │
│   Frontend   │         │     Backend      │
└──────┬───────┘         └────────┬─────────┘
       │  1. POST /login          │
       │─────────────────────────>│
       │                          │  validate credentials
       │  2. JWT (httpOnly cookie)│  issue access + refresh
       │<─────────────────────────│
       │                          │
       │  3. GET /protected       │
       │  (+ CSRF token)          │
       │─────────────────────────>│  validate JWT + CSRF
       │  4. Protected data       │
       │<─────────────────────────│
       │                          │
       │  5. POST /refresh        │
       │─────────────────────────>│  rotate tokens
       │                          │
       │  6. POST /logout         │
       │─────────────────────────>│  invalidate session

Key Design Decisions

Decision	Choice	Rationale
Token storage	httpOnly cookies	Not accessible to JavaScript → mitigates XSS token theft
CSRF protection	Double-submit / token pattern	Required when using cookies
Token type	Short-lived access + refresh	Limits exposure window
State management	Context API for auth status	Centralized, lightweight

Why httpOnly cookies over localStorage? As I discussed in the storage blog, localStorage is readable by any script on the page—making it vulnerable to XSS. httpOnly cookies trade that risk for the need to handle CSRF, which we address below.

Step 1: Backend — Login and Token Issuance

On successful authentication, the backend issues a JWT and sets it as an httpOnly, secure cookie rather than returning it in the response body.

@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody LoginRequest request,
                               HttpServletResponse response) {
    // Authenticate credentials (delegated to AuthenticationManager)
    Authentication auth = authenticationManager.authenticate(
        new UsernamePasswordAuthenticationToken(
            request.getUsername(), request.getPassword()));

    String accessToken = jwtService.generateAccessToken(auth);
    String refreshToken = jwtService.generateRefreshToken(auth);

    // Set access token as httpOnly cookie
    ResponseCookie accessCookie = ResponseCookie.from("access_token", accessToken)
        .httpOnly(true)
        .secure(true)
        .path("/")
        .sameSite("Strict")
        .maxAge(Duration.ofMinutes(15))
        .build();

    response.addHeader(HttpHeaders.SET_COOKIE, accessCookie.toString());
    // Refresh token typically set on a scoped path, e.g. /api/auth/refresh

    return ResponseEntity.ok(new LoginResponse("Login successful"));
}

Key points:

httpOnly(true) prevents JavaScript access.
secure(true) ensures the cookie is only sent over HTTPS.
sameSite("Strict") adds a layer of CSRF defense (though we won't rely on it alone).

Step 2: Backend — CSRF Protection

Because we're using cookies, we need CSRF protection. Spring Security supports the double-submit cookie pattern via CookieCsrfTokenRepository.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .csrf(csrf -> csrf
            .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
            .csrfTokenRequestHandler(new SpaCsrfTokenRequestHandler()))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/auth/login", "/api/auth/refresh").permitAll()
            .anyRequest().authenticated())
        .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class);

    return http.build();
}

The CSRF token cookie is intentionally not httpOnly, because the frontend must read it and echo it back in a request header. The attacker's site can't read your cookies cross-origin, so this remains safe.

Step 3: Frontend — Configuring the HTTP Client

Configure your HTTP client to send cookies and include the CSRF token on state-changing requests.

import axios from "axios";

const api = axios.create({
  baseURL: "/api",
  withCredentials: true, // send cookies with every request
});

// Attach CSRF token from cookie to outgoing requests
api.interceptors.request.use((config) => {
  const csrfToken = getCookie("XSRF-TOKEN");
  if (csrfToken) {
    config.headers["X-XSRF-TOKEN"] = csrfToken;
  }
  return config;
});

function getCookie(name) {
  const match = document.cookie.match(new RegExp(`(^| )${name}=([^;]+)`));
  return match ? decodeURIComponent(match[2]) : null;
}

export default api;

Step 4: Frontend — Auth State with Context API

Since the JWT lives in an httpOnly cookie (invisible to JS), we track authentication status—not the token itself—in React Context.

import { createContext, useContext, useState, useEffect } from "react";
import api from "./api";

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  // On mount, check if an existing session is valid
  useEffect(() => {
    api.get("/auth/me")
      .then((res) => setUser(res.data))
      .catch(() => setUser(null))
      .finally(() => setLoading(false));
  }, []);

  const login = async (credentials) => {
    await api.post("/auth/login", credentials);
    const res = await api.get("/auth/me");
    setUser(res.data);
  };

  const logout = async () => {
    await api.post("/auth/logout");
    setUser(null);
  };

  return (
    <AuthContext.Provider value={{ user, loading, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
}

export const useAuth = () => useContext(AuthContext);

Design note: We don't store the token in Context or state—only the user's authenticated status. The browser handles the cookie automatically. This is the safest pattern.

Step 5: Frontend — Protecting Routes

Wrap protected routes so unauthenticated users are redirected.

import { Navigate } from "react-router-dom";
import { useAuth } from "./AuthContext";

export function ProtectedRoute({ children }) {
  const { user, loading } = useAuth();

  if (loading) return <div>Loading...</div>;
  if (!user) return <Navigate to="/login" replace />;

  return children;
}

Usage:

<Route
  path="/dashboard"
  element={
    <ProtectedRoute>
      <Dashboard />
    </ProtectedRoute>
  }
/>

Step 6: Handling Token Refresh

Short-lived access tokens improve security but require a refresh mechanism. A response interceptor can transparently retry after refreshing.

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    const original = error.config;

    if (error.response?.status === 401 && !original._retry) {
      original._retry = true;
      try {
        await api.post("/auth/refresh"); // rotates cookies server-side
        return api(original);            // retry original request
      } catch (refreshError) {
        // Refresh failed → force logout
        window.location.href = "/login";
        return Promise.reject(refreshError);
      }
    }
    return Promise.reject(error);
  }
);

Security tip: Implement refresh token rotation on the backend—issue a new refresh token on each use and invalidate the old one. This limits damage if a refresh token is ever compromised.

Step 7: Logout

Logout must clear cookies server-side, since the frontend can't touch httpOnly cookies.

@PostMapping("/logout")
public ResponseEntity<?> logout(HttpServletResponse response) {
    ResponseCookie clearedCookie = ResponseCookie.from("access_token", "")
        .httpOnly(true)
        .secure(true)
        .path("/")
        .maxAge(0) // expire immediately
        .build();

    response.addHeader(HttpHeaders.SET_COOKIE, clearedCookie.toString());
    // Also invalidate the refresh token in your store
    return ResponseEntity.ok(new LogoutResponse("Logged out"));
}

Common Pitfalls to Avoid

Pitfall	Consequence	Fix
CORS misconfiguration	Requests blocked or insecure	Configure allowed origins explicitly
Forgetting withCredentials	Cookies not sent	Set on HTTP client
Long-lived access tokens	Large exposure window	Short access + refresh tokens
Not rotating refresh tokens	Replay attacks	Rotate on every refresh
Skipping CSRF with cookie auth	CSRF vulnerability	Enable CSRF protection
Storing JWT in localStorage	XSS token theft	Use httpOnly cookies

Bringing It Together

A production-grade auth flow isn't a single feature—it's a coordinated system:

Login issues tokens as secure, httpOnly cookies.
CSRF protection guards cookie-based requests.
Context API tracks authentication status (never the token).
Protected routes gate access on the frontend.
Token refresh keeps sessions alive without long-lived tokens.
Logout clears state on both ends.

Each piece reinforces the others. Skip one, and you introduce a gap.

A Note on Verification

The code samples here are illustrative and follow common, widely-recommended patterns. Spring Security and React library APIs evolve, so:

Verify the exact API for your versions (e.g., Spring Security's CSRF configuration has changed across major releases).
Adapt cookie attributes (SameSite, domain, path) to your deployment topology.
Always test the full flow against your own security requirements.

This post completes the authentication series that began with the CSRF and storage articles. If there's a specific piece you'd like me to expand—refresh token rotation, CORS configuration, or role-based access—let me know.

Securing AI-Assisted Development Workflows: Best Practices for Enterprise Teams

Aswani Nayak — Fri, 21 Aug 2026 18:54:12 +0000

Introduction
AI coding assistants have moved from novelty to necessity. Tools that suggest, complete, and even generate entire functions are now embedded in the daily workflow of many development teams. In my earlier post, From Prompting to Production, I explored how to systematically integrate these tools into software delivery. But adoption without governance creates a new attack surface.

The uncomfortable truth is this: the same tools that accelerate your team can quietly leak your secrets, introduce vulnerabilities, and expand your compliance risk. For enterprise teams—where security, privacy, and auditability are non-negotiable—AI assistance demands the same rigor we apply to any other part of the SDLC.

This post lays out a practical framework for securing AI-assisted development, organized around four pillars: data protection, code validation, secret management, and team governance.

Why This Matters
Before diving into practices, it's worth being explicit about the risks:

Each of these is manageable—but only with intentional guardrails.

Pillar 1: Protect Sensitive Data and Source Code
The most immediate concern is what leaves your environment when developers use AI tools.

Recommended Practices
Understand the data flow. Know whether your AI tool sends code to external servers, and whether that data is used for training. Review the vendor's data retention and privacy terms carefully.
Prefer enterprise or self-hosted deployments. Where available, enterprise tiers often offer contractual guarantees that your data won't be used for model training and may support private deployments.
Classify your codebase. Not all repositories carry the same sensitivity. Establish clear rules about which projects may use AI assistance and which must not.
Use IDE-level controls. Many tools allow you to exclude specific files, directories, or file patterns (e.g., .env, config files) from being sent as context.

Note: Vendor capabilities vary and change frequently. Always verify current data-handling policies directly with your tool provider before relying on them.

Pillar 2: Validate AI-Generated Code
AI suggestions are plausible—not guaranteed correct or secure. Treat all generated code as untrusted until reviewed.

A Practical Review Checklist

Does it do what you intended? Read and understand every line before accepting.
Does it introduce known vulnerability patterns? Watch for injection risks, weak cryptography, improper input validation, and insecure defaults.
Does it follow your standards? Naming, error handling, logging, and architectural conventions still apply.
Is it tested? AI-generated code deserves the same test coverage as human-written code. Automate What You Can Integrate security scanning into your pipeline so that AI-generated code is subject to the same gates as everything else:

Code

# Example CI stage (illustrative)
security-checks:
  stage: verify
  script:
    - run-static-analysis     # SAST tooling
    - run-dependency-scan     # detect vulnerable dependencies
    - run-secret-scan         # catch committed secrets
  rules:
    - if: '$CI_PIPELINE_SOURCE'

Static analysis (SAST), dependency scanning, and secret detection are your safety net when a risky suggestion slips through review.

Pillar 3: Keep Secrets Out of Prompts and Suggestions
Secrets are especially dangerous in an AI context because they can be both leaked outward (pasted into a prompt) and suggested inward (autocompleted from patterns).

Recommended Practices

Never paste real credentials into prompts. Use placeholders when asking for help with authentication or configuration code.
Use secret managers. Keep credentials in a dedicated vault or secrets manager rather than in code that AI tools can read as context.
Enable pre-commit secret scanning. Catch accidental commits before they reach your repository.
Here's an example of writing auth code the right way—with no hardcoded secrets:

Code

// Good: secrets loaded from environment / secret manager
@Value("${jwt.secret}")
private String jwtSecret;

// Avoid: hardcoded secrets that AI tools may learn or expose
// private String jwtSecret = "super-secret-value";

This ties directly to enterprise auth patterns—like the JWT and CSRF approach I covered previously. Secure code and secure workflows reinforce each other.

Pillar 4: Establish Team Governance
Individual discipline isn't enough at enterprise scale. You need shared, documented rules.

Building an AI Usage Policy
Consider addressing these areas:

Approved tools. Maintain a list of vetted AI assistants and their permitted use contexts.
Prohibited data. Explicitly define what must never be shared with AI tools (customer data, secrets, regulated information).
Review requirements. Mandate human review and sign-off for AI-generated code, especially in security-sensitive areas.
Training. Ensure developers understand both the capabilities and the risks.
Auditability. Where possible, keep a record of how and where AI assistance is used in your codebase.
A Simple Adoption Maturity Model

Most enterprise teams should aim for at least Level 3.

Bringing It Together
Securing AI-assisted development isn't about slowing your team down—it's about making acceleration sustainable. The framework in short:

Protect data — control what leaves your environment.
Validate code — trust nothing until reviewed and scanned.
Guard secrets — keep credentials out of prompts and suggestions.
Govern usage — codify shared rules and enforce them. AI assistance is here to stay. The teams that win won't be the ones who adopt fastest—they'll be the ones who adopt safely.

What's Next?
In a future post, I'll dive deeper into integrating security scanning into CI/CD pipelines, expanding on Pillar 2 with concrete tooling patterns. If you found this useful, that's the natural next step in the series.

Have thoughts or experiences with securing AI workflows on your team? I'd love to hear them.

From Prompting to Production: A Practical Framework for AI-Assisted Software Development

Aswani Nayak — Wed, 22 Jul 2026 16:06:22 +0000

How structured workflows, context engineering, and human oversight can transform AI from a coding assistant into a true engineering partner.

Introduction

Generative AI is rapidly changing how software is built. While many development teams have experimented with AI-powered coding tools, the real challenge is not generating code—it's creating a repeatable process that produces reliable, high-quality outcomes.
Recently, we conducted a hands-on workshop to explore how AI can support the complete software development lifecycle. Rather than using toy examples, the session focused on solving a real business problem while applying a structured AI-assisted development workflow.
The result was more than just working software. We uncovered a practical framework that helps engineers collaborate effectively with AI agents, improve productivity, and maintain engineering quality.

The Importance of Preparation

One of the key messages before the workshop was simple:

Don't start with code. Start with understanding.

Developers were encouraged to review business requirements in advance and become familiar with the problem domain before engaging coding agents.
The goal was not simply to generate code faster, but to:
• Understand the business problem
• Validate AI-generated outputs
• Review implementation plans critically
• Verify test cases before implementation
The workshop reinforced a crucial principle:

AI can accelerate development, but humans remain responsible for understanding the business intent.

The Shift from Prompt Engineering to Context Engineering

Many discussions about AI focus on writing the perfect prompt.
The workshop highlighted something more important:
Context engineering.
The best outcomes occurred when engineers supplied:
• Business objectives
• Functional requirements
• Acceptance criteria
• System context
• Integration dependencies
• Architectural constraints
• Source-of-truth considerations
Instead of immediately asking an AI agent to generate code, the team first provided comprehensive context and required the agent to fully understand the problem.
For example:

"I want to create a new Spring Boot application for a sales platform. Review the requirements, understand the acceptance criteria, and grill me on the requirements before creating an implementation plan."

The business requirement explained that sellers needed a streamlined way to serve customers while relying on existing systems as the source of truth and avoiding unnecessary data duplication across platforms.
Providing this level of context dramatically improved the quality of AI-generated plans, test cases, and implementation recommendations.

The "Grill Me" Approach

One of the most valuable concepts introduced during the workshop was the Grill Me technique.
Rather than immediately proposing a solution, the AI agent is instructed to challenge assumptions and ask follow-up questions until it understands the requirements thoroughly.
This transforms the agent from a code generator into a business analyst.
Instead of guessing, the AI asks questions such as:
• What business outcome are we trying to achieve?
• What systems currently own the data?
• What are the integration constraints?
• What are the edge cases?
• What constitutes success?
The objective is to eliminate ambiguity before planning or implementation begins.
This often uncovers gaps in requirements long before development starts.

A Structured AI Development Workflow

The workshop followed a repeatable workflow designed to maximize AI effectiveness while preserving engineering discipline.

Step 1: Requirement Discovery

Provide the business requirements to the AI agent and ask it to fully understand the request before proposing a solution.
The agent should review the available context and ask clarifying questions until requirements are well understood.
Outcome: Clear understanding of the problem.

Step 2: Implementation Planning

Once requirements are understood, the AI generates:
• Solution architecture
• Technical approach
• Task breakdown
• Risks and assumptions
Outcome: An actionable implementation plan.

Step 3: Human Review

Developers review the proposed plan and challenge assumptions.
This is one of the most important phases in the process.
The objective is not to approve the plan blindly but to verify:
• Architectural decisions
• Business alignment
• Missing requirements
• Technical feasibility
Outcome: A validated implementation strategy.

Step 4: Test-Driven Development

Before writing code, the AI generates test cases.
A structured TDD approach encourages engineers to define expected system behavior before implementation begins.
Benefits include:
• Better requirement validation
• Improved quality
• Higher confidence in outcomes
• Earlier detection of requirement gaps
Outcome: Comprehensive test coverage aligned to business needs.

Step 5: Review Test Cases

Developers review generated tests to ensure:
• Requirements are fully represented
• Edge cases are covered
• Acceptance criteria are addressed
Strong test cases frequently reveal requirement gaps before implementation starts.
Outcome: Reliable validation criteria.

Step 6: Code Implementation

After requirements, plans, and tests have been validated, the AI generates implementation code.
Because the earlier phases established strong guardrails, implementation quality improves significantly.
Outcome: Faster and more accurate development.

Step 7: Validation and Refinement

AI-generated code should never be considered production-ready by default.
Engineers still perform:
• Code reviews
• Functional validation
• Performance verification
• Security checks
• Refinement and optimization
Outcome: Production-quality software.

Why This Approach Works

Several important lessons emerged from the workshop.
Requirements Quality Drives AI Quality
The quality of the output is directly related to the quality of the requirements provided.
Clear business requirements consistently produce:
• Better implementation plans
• Better test coverage
• Better code quality

Human Oversight Remains Critical

AI can accelerate analysis, planning, testing, and coding.
It cannot replace engineering judgment.

Developers remain responsible for:
• Understanding business intent
• Challenging assumptions
• Evaluating architecture
• Ensuring quality

TDD Complements AI Extremely Well

Generating tests before implementation creates a powerful partnership between developers and AI agents.
Tests provide structure, define expectations, and reduce ambiguity.
The combination of AI-generated tests and human review proved particularly effective.

Process Matters More Than the Model

One of the most surprising lessons was that success depended less on the specific AI model being used and more on the workflow surrounding it.
Teams often focus on finding the "best" model.
In reality, a disciplined process consistently delivered better results than relying on model capabilities alone.

The Evolving Role of Developers

Perhaps the most significant takeaway is that software engineering is evolving.
Developers are spending less time writing repetitive code and more time:
• Understanding business problems
• Evaluating solutions
• Reviewing AI-generated outputs
• Designing systems
• Defining quality standards
• Making architectural decisions
The most valuable engineering skill is no longer typing code quickly.
It is providing the right context, asking the right questions, and validating the right outcomes.

Conclusion

The future of software development is not about replacing engineers with AI.
It is about creating an effective partnership between human expertise and AI capabilities.
The workshop demonstrated that successful AI adoption begins long before code generation. It starts with understanding requirements, providing rich context, challenging assumptions, reviewing plans, validating tests, and maintaining ownership of quality throughout the development lifecycle.
When combined with a disciplined workflow, AI becomes more than a productivity tool—it becomes a force multiplier for engineering teams.

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.

DEV Community: Aswani Nayak

Role-Based and Permission-Based Access Control in Spring Security

Introduction

Roles vs. Permissions: What's the Difference?

A note on Spring's naming

Modeling Roles and Permissions

Mapping to Spring Security Authorities

Approach 1: URL-Based Authorization

Approach 2: Method-Level Authorization

@PreAuthorize — check before the method runs

Using method arguments in expressions

@PostAuthorize — check after the method runs

Approach 3: Custom Permission Logic

Connecting to the Frontend

Common Pitfalls to Avoid

Bringing It Together

A Note on Verification

If you'd like, I can expand this into a focused follow-up on testing authorization rules or integrating an external identity provider (like Keycloak) for centralized RBAC. Let me know.

Building a Full Enterprise-Ready React + Spring Boot Auth Flow: An End-to-End Guide

Introduction

Architecture Overview

Key Design Decisions

Step 1: Backend — Login and Token Issuance

Step 2: Backend — CSRF Protection

Step 3: Frontend — Configuring the HTTP Client

Step 4: Frontend — Auth State with Context API

Step 5: Frontend — Protecting Routes

Step 6: Handling Token Refresh

Step 7: Logout

Common Pitfalls to Avoid

Bringing It Together

A Note on Verification

Securing AI-Assisted Development Workflows: Best Practices for Enterprise Teams

From Prompting to Production: A Practical Framework for AI-Assisted Software Development

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

Storing Personal Information in React: sessionStorage vs Context API

`@PreAuthorize` — check before the method runs

`@PostAuthorize` — check after the method runs