Spring Security is a powerful and customizable authentication and access-control framework for Java applications. However, in certain development or testing scenarios, developers may want to temporarily disable Spring Security to bypass authentication and authorization mechanisms. Let us delve into understanding how to deactivate Spring Security in a project.
1. What is Spring Security?
Spring Security is a powerful and customizable authentication and access-control framework for Java applications. It is the standard for securing Spring-based applications. It protects against attacks such as session fixation, clickjacking, cross-site request forgery (CSRF), and more. Spring Security is highly flexible and extensible, supporting both standard authentication mechanisms (like HTTP Basic, Form Login, and OAuth2) and custom security logic. It integrates seamlessly with Spring Boot and other Spring modules.
1.1 Key Features of Spring Security
- Authentication – Verifying the identity of a user or system.
- Authorization – Granting or denying access to resources based on roles or permissions.
- Protection Against Common Attacks – Built-in defenses against CSRF, XSS, and clickjacking.
- Session Management – Secure handling of sessions and concurrent login control.
- Integration – Works with standard protocols like LDAP, OAuth2, and OpenID Connect.
1.2 Disabling Spring Security (for development or customization)
There are several ways to disable or bypass Spring Security, particularly for non-production environments or when writing custom security configurations:
- Using properties in
application.properties: You can disable default security settings with properties likespring.security.enabled=false(deprecated in newer versions, prefer custom configuration). - Creating a custom security configuration: By extending
WebSecurityConfigurerAdapter(or implementingSecurityFilterChainin newer Spring versions), you can fully control which endpoints are secured. - Removing Spring Security dependency: You can remove the Spring Security starter dependency from your
pom.xmlorbuild.gradle, but this is not recommended for production or when using Spring Boot starters. - Overriding security filters: You can register your filter chain and override the default behavior using custom filters or explicitly allowing all requests.
While disabling Spring Security might be useful in the early development stages, it’s highly recommended to keep security mechanisms in place for production-grade applications. You can fine-tune which routes or resources should be secured based on your business logic.
2. Different Ways to Disable Spring Security (with Code Examples)
2.1 Disable Security via Configuration
This is the most common and clean way to disable or customize Spring Security, especially in development environments. It involves overriding the default security configuration using Java-based configuration. In Spring Security 5.7 and above, the preferred approach is to define a SecurityFilterChain bean instead of extending WebSecurityConfigurerAdapter (which is now deprecated).
Below is an example where we disable CSRF protection and allow unrestricted access to all HTTP requests:
package com.example.demo;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
@Configuration
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf().disable() // Disable CSRF protection
.authorizeHttpRequests(auth -> auth
.anyRequest().permitAll() // Allow all requests without authentication
);
return http.build();
}
}
The provided code defines a Spring Security configuration class named SecurityConfig, annotated with @Configuration to mark it as a source of bean definitions. Inside this class, a SecurityFilterChain bean is declared using the @Bean annotation, which is the modern and recommended approach starting from Spring Security 5.7. The method filterChain(HttpSecurity http) customizes the HTTP security configuration by first disabling CSRF protection using csrf().disable(), which is typically safe for stateless APIs or development environments. Then, it configures authorization using authorizeHttpRequests(), specifying that all incoming HTTP requests should be permitted without authentication using anyRequest().permitAll(). Finally, http.build() constructs and returns the customized security filter chain. This configuration effectively disables all security restrictions, making the application accessible to all requests, which is useful for testing or public resources but should not be used in production environments.
2.1.1 When to Use?
- In development or local environments where security is not a concern.
- For public-facing endpoints like health checks or status pages.
- To simplify testing when authentication is not yet implemented.
2.1.2 Best Practices
- Do not use this configuration in production unless your application is behind a trusted gateway or firewall.
- Segment public and private endpoints with different security rules rather than permitting all requests globally.
- Use Spring Profiles to enable/disable this configuration based on the environment.
To learn more, refer to the official Spring Security Java Configuration Guide.
2.2 Exclude Spring Security Dependency (Not Recommended)
One of the most straightforward—but least flexible—ways to disable Spring Security is by removing the Spring Security dependency from your project’s build file. This method effectively disables all security features by preventing Spring Boot from auto-configuring any security filters or behaviors. While this might seem like a quick fix during early development or prototyping, it is strongly discouraged for long-term use, especially in applications intended for production.
In pom.xml for Maven projects, you can do this by simply commenting out or removing the spring-boot-starter-security dependency:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
Similarly, in Gradle projects using build.gradle, you can remove or comment out the following:
// implementation 'org.springframework.boot:spring-boot-starter-security'
2.2.1 Why This Is Not Recommended?
- No Future Flexibility: If you decide to reintroduce security later, you’ll have to refactor and reconfigure security-related features from scratch.
- Hidden Risks: Without Spring Security, your app has zero built-in protection against common vulnerabilities like CSRF, CORS, clickjacking, and unauthorized access.
- Breaks Auto-Configuration: Some other Spring Boot starters assume security is present, and removing the dependency could lead to unexpected behavior or errors.
While removing the dependency disables all security concerns entirely, it is best used only in throwaway test projects or when experimenting with minimal setups. Production-grade applications should always use proper security controls, even if minimal.
2.3 Disable Security for Specific Endpoints
In some cases, you might want to allow unauthenticated access to specific endpoints while keeping security enabled for the rest of your application. This method provides a fine-grained way to disable security for particular routes or URL patterns, which is useful for public endpoints such as API health checks, static resources, or login pages.
The following code snippet demonstrates how to disable security for endpoints that match a specific pattern (in this case, /public/**) while requiring authentication for all other requests:
package com.example.demo;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
@Configuration
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf().disable() // Disables CSRF protection for testing purposes
.authorizeHttpRequests(auth -> auth
.requestMatchers("/public/**").permitAll() // Allows public access to /public/** endpoints
.anyRequest().authenticated() // Requires authentication for all other endpoints
);
return http.build();
}
}
The provided code demonstrates how to disable Spring Security for specific endpoints while keeping it enabled for others by configuring a SecurityFilterChain bean. The class SecurityConfig is annotated with @Configuration to define Spring’s security configuration. Inside the filterChain method, csrf().disable() disables CSRF protection, typically used for stateless applications or APIs. The method authorizeHttpRequests() is then used to configure access control: requestMatchers("/public/**").permitAll() allows unauthenticated access to all endpoints that match the pattern /public/** (e.g., public APIs or static resources), while anyRequest().authenticated() ensures that any other request requires authentication. This approach allows fine-grained control over which parts of the application should be publicly accessible and which require user authentication, making it useful for serving public resources like status endpoints or static files without compromising overall security for the rest of the app.
2.3.1 When to Use?
- Public Resources: For serving non-sensitive data such as public APIs, images, or static files that need to be accessed without authentication.
- Health Checks: For applications that expose health or status endpoints that need to be accessible by monitoring systems or external services without requiring a login.
- Prototyping or Debugging: During development, when you want to quickly test public endpoints without bothering with authentication configurations.
2.3.2 Best Practices
- Only disable security for endpoints that are genuinely safe to be accessed by anyone. Public endpoints should be designed to not expose sensitive or private data.
- Consider using Spring Profiles to toggle this configuration based on the environment. For example, you might want to disable security for certain endpoints in a development profile but keep it for production.
- Be mindful of potential security holes. For example, even publicly accessible endpoints should be protected from malicious behavior, like SQL injection or other vulnerabilities.
2.4 Disable Security via Profile-based Configuration
Spring profiles allow you to customize your application’s configuration based on the active environment (e.g., dev, test, prod). You can use profiles to conditionally disable security in specific environments, which is particularly useful when you want to simplify configurations during development or testing while keeping security features intact for production. Profile-based configuration ensures that the security settings you apply are environment-specific, reducing the risk of exposing sensitive data in the wrong context.
The code below demonstrates how to disable Spring Security in a development environment (dev) while keeping it active in others:
You can conditionally disable security using Spring profiles for different environments (e.g. dev, test).
@Configuration
@Profile("dev")
public class DevSecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf().disable() // Disables CSRF protection for dev profile
.authorizeHttpRequests(auth -> auth
.anyRequest().permitAll() // Permits all requests in dev environment
);
return http.build();
}
}
In this example, the @Profile("dev") annotation ensures that this configuration is only loaded when the dev profile is active. The filterChain method disables CSRF protection and allows all requests without authentication, which is typical for development or testing environments. This configuration ensures that security is relaxed in a controlled, non-production environment but can be configured differently for other environments.
To activate this profile, you can set the spring.profiles.active property in your application.properties or application.yml file:
spring.profiles.active=dev
2.4.1 When to Use?
- Development and Testing: You can disable security in a development profile to streamline development and testing, focusing on application logic instead of security concerns.
- Environment-Specific Configurations: Profile-based configuration allows you to tailor security settings for different environments, enabling you to have stricter controls in production and more relaxed configurations in non-production environments.
- Continuous Integration (CI) and Continuous Deployment (CD): You can use profiles to automatically disable or adjust security during CI/CD pipelines or deployment in different environments.
2.4.2 Best Practices
- Never leave security disabled in production or publicly accessible environments. Always ensure that production environments are fully secured, even if you disable security in dev/test profiles.
- Use environment-specific properties or YAML files to keep configurations clean and maintainable (e.g.,
application-dev.properties,application-prod.properties). - Ensure that the active profile is correctly set in your deployment pipeline to prevent accidental misconfigurations, especially in production.
3. Conclusion
Disabling Spring Security is useful in the development and testing phases to quickly bypass authentication layers. However, it should be avoided in production environments. We explored various methods including property-based disabling, profile-specific configs, and full configuration overrides. Make sure to re-enable security features before moving to staging or production.
