Skip to content
BSWEN
Blog

When Should You Add Spring Security to a Spring Boot Project?

Cowrie
Cowrie
Dev @ Bswen

I was building a Spring Boot project with heavy RBAC requirements and multi-tenancy when I hit a wall: should I integrate Spring Security now or wait until the core features are done?

This isn’t just a theoretical question. The wrong timing can mean either:

  • Wasting hours fighting security configs when you just want to test endpoints
  • OR, refactoring your entire data access layer because you didn’t account for tenant isolation

Let me walk through how I decided, and what I learned from the community.

The Core Question

A Reddit thread in r/SpringBoot captured this exact dilemma:

“I have started a project where RBAC is very important and it’s a multi tenant app. Now I’m not able to decide when to add Spring Security.”

The responses fell into three camps:

Early adoption:

“If your app needs different data or access based on username/client you want to add it as early as possible.”

Late adoption:

“Build the base features of your project then add the spring security part.”

Pragmatic middle:

“Build some functionality and then, wire up the security to your role’s needs. That way is so much easier to determine how basic or engineered your implementation needs to be.”

So which is right? It depends on your app’s needs.

Decision Framework

Here’s how I now approach this decision:

Decision Tree
START
  |
  v
Does your app need RBAC or multi-tenancy?
  |
  +-- YES --> Add Spring Security EARLY
  |              |
  |              v
  |           User identity affects data access?
  |              |
  |              +-- YES --> Security is CORE to architecture
  |              |            Design with security from day 1
  |              |
  |              +-- NO --> Use minimal "permit-all" config
  |                          Tighten incrementally
  |
  +-- NO --> Can you build core features without auth?
               |
               +-- YES --> Add Spring Security LATER
               |            Focus on business logic first
               |
               +-- NO --> Add basic auth now
                          Expand as needed

When to Add Security EARLY

Add Spring Security at the start when:

  1. RBAC is a core requirement - Different roles see different data
  2. Multi-tenancy is fundamental - Tenant isolation affects every query
  3. User identity drives business logic - Your service layer depends on “who is asking”
  4. Compliance from day one - Healthcare, finance, or regulated industries

The Minimal Dev Config

Start with a permissive config that lets you develop without friction:

SecurityConfig.java
@Configuration
@EnableWebSecurity
public class SecurityConfig {


    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        // During development: permit all requests
        http.authorizeHttpRequests(auth -> auth.anyRequest().permitAll())
            .csrf(csrf -> csrf.disable());


        return http.build();
    }
}

This gives you:

  • Spring Security on the classpath (dependencies resolved)
  • No authentication blocking your development
  • Easy to tighten later

Incremental Security Addition

As features stabilize, add constraints:

SecurityConfig.java
@Configuration
@EnableWebSecurity
public class SecurityConfig {


    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .requestMatchers("/api/admin/**").hasRole("ADMIN")
            .requestMatchers("/api/user/**").hasAnyRole("USER", "ADMIN")
            .anyRequest().authenticated()
        )
        .sessionManagement(session -> session
            .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        );


        return http.build();
    }
}

When to Add Security LATER

Delay Spring Security when:

  1. Building a prototype/MVP - Speed matters more than security
  2. Learning Spring Boot - Don’t add complexity while learning basics
  3. Auth is an afterthought - Simple CRUD app with no user-specific data
  4. API-first development - Build the API, then add auth layer

The risk here is architectural debt. If you later realize you need RBAC, you might face:

Late Security Refactor Pain Points
BEFORE (No Security):
  Controller -> Service -> Repository -> Database
  (All data flows freely)


AFTER (RBAC Added):
  Controller -> Security Check -> Service -> Tenant Filter -> Repository
  (Every layer needs modification)

Multi-Tenant Security: Why Early Matters

Multi-tenancy is where late security adoption hurts most. Consider:

TenantAwareService.java
@Service
public class TenantAwareService {


    @PreAuthorize("hasRole('TENANT_USER') and @tenantSecurity.checkAccess(#tenantId)")
    public TenantData getTenantData(String tenantId) {
        // Data is automatically filtered by tenant
        return tenantRepository.findById(tenantId);
    }
}

If you build without tenant isolation from the start:

  • Every query needs tenant filtering added
  • Your data model might not support tenant partitioning
  • Testing becomes complex (data leakage risks)

Common Mistakes I’ve Seen

  1. Security as afterthought in RBAC apps - The code assumes “current user” exists everywhere
  2. Full security too early - Every endpoint needs auth tokens, even during development
  3. Ignoring security until production - Panic-driven security implementation
  4. No tenant isolation planning - Realizing late that every table needs a tenant_id

My Recommendation

For most projects, use the hybrid approach:

  1. Add Spring Security dependency early
  2. Configure with permitAll() during active development
  3. Define your role/permission model on paper (even if not enforced)
  4. Incrementally add constraints as features stabilize
  5. Before production: audit and tighten everything

This keeps your development velocity high while avoiding architectural debt.

Quick Reference

Timing Summary
┌─────────────────────┬────────────────┬─────────────────────┐
│ Scenario            │ When to Add    │ Approach           │
├─────────────────────┼────────────────┼─────────────────────┤
│ RBAC Required       │ Early          │ Minimal config,    │
│                     │                │ tighten gradually  │
├─────────────────────┼────────────────┼─────────────────────┤
│ Multi-tenant        │ Very Early     │ Design with tenant │
│                     │                │ isolation from day 1│
├─────────────────────┼────────────────┼─────────────────────┤
│ Simple CRUD         │ Later          │ Build features,    │
│                     │                │ add auth when needed│
├─────────────────────┼────────────────┼─────────────────────┤
│ MVP/Prototype       │ Last           │ Speed first,       │
│                     │                │ security later     │
├─────────────────────┼────────────────┼─────────────────────┤
│ Regulated Industry  │ Day 1          │ Compliance         │
│                     │                │ requirements       │
└─────────────────────┴────────────────┴─────────────────────┘

The key insight: security timing isn’t about “early” or “late” - it’s about whether your business logic depends on user identity. If it does, start with security. If not, it can wait.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: