Disabling Spring Security for a Specific Profile in Spring Boot

Let's face it: not every environment needs the same security. In production, you lock everything down with OAuth2, JWT, or form login. But in local development or integration tests, that security layer is a pain. You just want to hit your endpoints without generating tokens or dealing with CSRF. The naive approach—commenting out security config—works until you commit it. Then someone pushes to production and you have an incident.

I've seen teams disable security globally with @EnableWebSecurity(false) or exclude SecurityAutoConfiguration from auto-configuration. Both are fragile and can lead to security holes. The right way is to conditionally disable Spring Security for a specific profile using Spring's profile mechanism. This keeps your production security intact while giving developers a friction-free local experience.

In this article, I'll show you the battle-tested approaches to disable Spring Security for a specific profile. I'll cover the classic Servlet stack, WebFlux, and the gotchas that the official docs gloss over. By the end, you'll have a clean, maintainable solution that won't bite you in production.

The Right Way: Using @Profile on a Security Configuration

The cleanest approach is to create a configuration class that extends WebSecurityConfigurerAdapter (for Servlet-based apps) or defines a SecurityWebFilterChain bean (for WebFlux) and annotate it with @Profile. This class will override the security settings to permit all requests. The key is to have this configuration active only for the desired profile, while the default security configuration (from auto-configuration) remains active for all other profiles.

Here's a concrete example for a Servlet-based Spring Boot application. Assume you have a profile called dev where you want to disable security.

import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Profile("dev")
@Configuration
public class DevSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .anyRequest().permitAll()
            .and()
                .csrf().disable()
                .headers().frameOptions().disable(); // For H2 console
    }
}

Alternative: Using @ConditionalOnMissingBean and a No-Op Config

Another approach is to define a no-op security configuration that is conditionally created only if no other security configuration is present. This is useful if you want to completely disable Spring Security (including auto-configuration) for a profile. However, this approach is riskier because it removes all security auto-configuration, which might include other important beans like SecurityProperties.

Here's how you can do it: Create a configuration class that defines a SecurityFilterChain bean (or extends WebSecurityConfigurerAdapter) and annotate it with @ConditionalOnMissingBean(SecurityFilterChain.class). Then, use @Profile to limit it to the desired profile.

But I recommend the first approach over this one. The reason: @ConditionalOnMissingBean can lead to subtle bugs if the order of bean creation changes. Also, if you have multiple security configurations, you might accidentally create multiple SecurityFilterChain beans.

import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Profile("dev")
@Configuration
public class NoOpSecurityConfig {

    @Bean
    @ConditionalOnMissingBean(SecurityFilterChain.class)
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .anyRequest().permitAll()
            .and()
                .csrf().disable();
        return http.build();
    }
}

What the Official Docs Won't Tell You

The Spring Security reference guide tells you how to configure security, but it doesn't tell you the pitfalls of disabling it for a profile. Here are the gotchas I've seen in production:

1. Profile name mismatch: The @Profile annotation value must exactly match the active profile name. Case-sensitive. I've seen developers use @Profile("dev") but the environment variable set SPRING_PROFILES_ACTIVE=DEV (uppercase). It won't match.
2. Auto-configuration still runs: Even if you define your own SecurityFilterChain, Spring Boot's security auto-configuration still runs and creates beans like SecurityProperties. This can lead to unexpected behavior if you're not careful. For example, the default security properties might still enforce a login page.
3. Actuator endpoints: If you have Spring Boot Actuator, security for actuator endpoints is configured separately. Disabling security for the main app doesn't automatically disable it for actuator endpoints. You need to configure them explicitly.
4. Testing: When writing tests with @WebMvcTest, the security auto-configuration is still applied. You need to explicitly exclude security auto-configuration or use @AutoConfigureMockMvc(addFilters = false). But if you're testing a profile-specific config, use @ActiveProfiles("dev").
5. Multiple security filter chains: If you have multiple SecurityFilterChain beans (e.g., one for API and one for web), disabling security for a profile means you need to handle both. The @Profile approach works per bean.
6. WebFlux vs Servlet: The approach for WebFlux is similar but uses SecurityWebFilterChain instead. Don't mix them up.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.security.config.annotation.web.reactive.EnableWebFluxSecurity;
import org.springframework.security.config.web.server.ServerHttpSecurity;
import org.springframework.security.web.server.SecurityWebFilterChain;

@Profile("dev")
@Configuration
@EnableWebFluxSecurity
public class WebFluxDevSecurityConfig {

    @Bean
    public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
        http
            .authorizeExchange()
                .anyExchange().permitAll()
            .and()
                .csrf().disable();
        return http.build();
    }
}

Testing Your Profile-Specific Security Configuration

You must test that your profile-specific security works correctly. Write integration tests that activate the profile and verify that endpoints are accessible without authentication. Also write tests for the default profile to ensure security is enabled.

Use @SpringBootTest with @ActiveProfiles("dev") to load the application with the dev profile. Then use TestRestTemplate or MockMvc to make requests without authentication and assert that you get a 200 response instead of 401/403.

For the production profile, you can test with @ActiveProfiles("prod") and expect that unauthenticated requests are rejected.

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.web.client.TestRestTemplate;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.test.context.ActiveProfiles;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ActiveProfiles("dev")
class SecurityProfileTest {

    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    void shouldAllowUnauthenticatedAccessInDevProfile() {
        ResponseEntity<String> response = restTemplate.getForEntity("/api/public", String.class);
        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
    }

    @Test
    void shouldAllowAccessToAnyEndpoint() {
        ResponseEntity<String> response = restTemplate.getForEntity("/api/private", String.class);
        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
    }
}

Common Mistakes and How to Avoid Them

Here are the most common mistakes I've seen when disabling Spring Security for a profile:

1. Using spring.autoconfigure.exclude in profile-specific properties: This disables all security auto-configuration, which can have unintended side effects. As mentioned in the production incident, this is fragile.
2. Forgetting to disable CSRF: In development, you often need to disable CSRF for tools like Postman or Swagger. If you don't, you'll get 403 errors on POST requests.
3. Not disabling frame options: If you use H2 console or Swagger UI, you need to disable frame options to allow rendering in iframes.
4. Profile name mismatch: Ensure the profile name in @Profile matches exactly the active profile name. Use lowercase and avoid typos.
5. Overriding the wrong method: In WebSecurityConfigurerAdapter, you need to override configure(HttpSecurity). Overriding configure(AuthenticationManagerBuilder) won't disable security.
6. Not testing: Many developers assume the config works without testing. Write tests as shown above.

// WRONG: Using spring.autoconfigure.exclude in properties
// application-dev.properties:
// spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration

// CORRECT: Using @Profile on a configuration class
@Profile("dev")
@Configuration
public class DevSecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests().anyRequest().permitAll()
            .and().csrf().disable()
            .headers().frameOptions().disable();
    }
}

Disabling Security for WebFlux Applications

If you're using Spring WebFlux, the approach is similar but you use SecurityWebFilterChain instead of WebSecurityConfigurerAdapter. Create a @Configuration class annotated with @Profile and define a SecurityWebFilterChain bean that permits all requests.

Note that WebFlux security auto-configuration is separate from Servlet stack. You need to ensure you're not mixing them. If your application uses WebFlux, use the reactive security configuration.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.security.config.annotation.web.reactive.EnableWebFluxSecurity;
import org.springframework.security.config.web.server.ServerHttpSecurity;
import org.springframework.security.web.server.SecurityWebFilterChain;

@Profile("dev")
@Configuration
@EnableWebFluxSecurity
public class ReactiveDevSecurityConfig {

    @Bean
    public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
        http
            .authorizeExchange()
                .anyExchange().permitAll()
            .and()
                .csrf().disable()
                .headers().frameOptions().disable();
        return http.build();
    }
}