Introduction

In Spring Boot 2.0, if Spring Security is on the classpath, Boot auto-configures a default security setup. That usually means all endpoints become protected, a generated password appears in the logs, and a basic login flow is enabled.

If you want the application completely unsecured for local development or because you plan to provide your own security configuration, you need to either exclude the auto-configuration or replace it with an explicit SecurityFilterChain configuration.

What "Default Security" Means

With Spring Boot 2.0 and Spring Security present, Boot provides a fallback configuration. You often see behavior like:

• all HTTP endpoints require authentication
• a generated password is logged at startup
• form login or HTTP Basic is enabled automatically

This is useful as a safe default, but it is rarely what you want for a real application beyond the initial bootstrap stage.

Option 1: Exclude Security Auto-Configuration

If you truly want Spring Boot not to set up default security at all, exclude the security auto-configuration classes.

1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3import org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration;
4import org.springframework.boot.actuate.autoconfigure.security.servlet.ManagementWebSecurityAutoConfiguration;
5
6@SpringBootApplication(exclude = {
7    SecurityAutoConfiguration.class,
8    ManagementWebSecurityAutoConfiguration.class
9})
10public class DemoApplication {
11    public static void main(String[] args) {
12        SpringApplication.run(DemoApplication.class, args);
13    }
14}

This is the blunt instrument approach. It turns off Boot's default servlet security setup and, if Actuator is involved, avoids the management endpoint security auto-configuration too.

Option 2: Provide Your Own Security Configuration

A more controlled approach is to keep Spring Security and define your own rules explicitly.

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.security.config.annotation.web.builders.HttpSecurity;
4import org.springframework.security.web.SecurityFilterChain;
5
6@Configuration
7public class SecurityConfig {
8
9    @Bean
10    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
11        http
12            .authorizeHttpRequests(auth -> auth.anyRequest().permitAll())
13            .csrf(csrf -> csrf.disable());
14
15        return http.build();
16    }
17}

This approach is usually better than excluding everything, because it makes the application's security intent explicit and leaves room to tighten rules later.

Why Not Just Remove the Dependency?

If the application does not need Spring Security at all, the simplest option is often to remove the dependency from the project rather than disabling its behavior after loading it.

That said, if other parts of the application need security classes or you plan to add custom rules shortly, keeping the dependency and overriding the default behavior can be reasonable.

Actuator Endpoints Need Extra Attention

In Spring Boot 2.0, Actuator endpoints can be affected separately. If you disable only general web security but forget management security configuration, Actuator behavior may still surprise you.

That is why the auto-configuration exclusion example commonly includes both SecurityAutoConfiguration and ManagementWebSecurityAutoConfiguration.

Development Versus Production

Disabling default security can make local development easier, but it is not a production strategy. If the app is meant to be reachable by users or other systems, write an explicit security policy instead of leaving everything open.

Treat "disable default security" as either:

• a local development convenience
• a transition step before custom security rules
• a deliberate choice for an internal non-sensitive service

It should not become an accidental permanent state.

Common Pitfalls

• Excluding security auto-configuration when the real need was just to permit a few endpoints.
• Forgetting that Actuator endpoints may have separate management security behavior.
• Disabling everything in development and then accidentally shipping the same config to production.
• Keeping Spring Security on the classpath and being surprised when Boot auto-configures it.
• Using broad exclusions when an explicit custom SecurityFilterChain would be clearer.

Summary

• Spring Boot 2.0 enables a default security setup when Spring Security is on the classpath.
• You can disable it by excluding SecurityAutoConfiguration, and often ManagementWebSecurityAutoConfiguration too.
• A better long-term approach is usually to provide your own security configuration explicitly.
• If you do not need Spring Security at all, removing the dependency may be simplest.
• Be careful not to turn a development shortcut into an unintended production policy.