Introduction

If a Spring Boot app unexpectedly shows a login page, Spring Security auto-configuration is usually active. Adding spring-boot-starter-security enables default authentication rules that protect endpoints and render a generated login form. This is expected behavior, but confusing when security dependency is added transitively or before custom config is ready. This guide explains why it happens and how to configure desired access behavior.

Why the Default Login Page Appears

When Spring Security is on classpath and no custom SecurityFilterChain is provided, Boot secures all endpoints by default and serves a built-in login page.

Check dependencies:

./mvnw dependency:tree | grep spring-boot-starter-security

Or Gradle equivalent to confirm how security starter was included.

Option 1: Configure Explicit Security Rules

Define your own security chain:

1@Bean
2SecurityFilterChain security(HttpSecurity http) throws Exception {
3  return http
4      .authorizeHttpRequests(auth -> auth
5          .requestMatchers("/", "/public/**").permitAll()
6          .anyRequest().authenticated())
7      .formLogin(form -> form.loginPage("/login").permitAll())
8      .build();
9}

Now behavior is explicit and no longer default-global.

Option 2: Disable Security for Local Prototyping

For temporary local debugging only, allow all requests.

1@Bean
2SecurityFilterChain devOnly(HttpSecurity http) throws Exception {
3  return http
4      .csrf(csrf -> csrf.disable())
5      .authorizeHttpRequests(auth -> auth.anyRequest().permitAll())
6      .build();
7}

Do not ship this to production environments.

Option 3: Remove Unneeded Security Dependency

If app should be public and has no auth requirements yet, remove security starter from build file.

1<!-- remove if not needed -->
2<dependency>
3  <groupId>org.springframework.boot</groupId>
4  <artifactId>spring-boot-starter-security</artifactId>
5</dependency>

This removes automatic login page behavior entirely.

Troubleshooting Checklist

• Confirm active profiles and environment-specific security configs.
• Verify no extra security config classes are loaded unintentionally.
• Ensure custom login template mapping exists if you configured custom login path.

curl -I http://localhost:8080/

HTTP 302 to /login confirms auth redirection behavior.

Verification and Debugging Workflow

A repeatable validation workflow prevents one-off fixes that break in CI or production. Use a three-phase approach: reproduce, isolate, and confirm. First, capture baseline behavior with a minimal reproducible command or test. Second, apply one focused change at a time so causal impact is clear. Third, rerun the same checks and at least one adjacent scenario to ensure the fix generalizes.

A compact workflow looks like this:

1# 1) capture baseline state
2./run_example.sh > before.txt
3
4# 2) apply focused fix
5# update code/config described in this article
6
7# 3) verify expected behavior
8./run_example.sh > after.txt
9diff -u before.txt after.txt

When codebases include automated tests, convert the reproduced failure into a regression test. This makes your troubleshooting outcome durable and prevents silent regressions during dependency updates or refactors.

1# Example quality gate sequence
2./lint.sh
3./test.sh
4./smoke.sh

Production-Safe Rollout Checklist

Before shipping changes based on this solution, confirm environment parity and rollback readiness. A fix that works locally can still fail under different data volume, runtime versions, or network constraints.

Use this lightweight checklist:

• Confirm runtime/tool versions in staging match production.
• Validate behavior on representative data, not just toy examples.
• Add logs or metrics around the changed path for post-deploy visibility.
• Define rollback steps and execute a dry run if the change is high risk.
• Record the exact commands used for verification in PR or runbook notes.

A small investment in operational discipline drastically lowers incident risk and speeds up debugging if behavior differs across environments.

Common Pitfalls

• Assuming login page is a framework bug rather than default security auto-configuration.
• Adding security starter transitively and not noticing it in dependency graph.
• Defining partial security config that still protects all endpoints unexpectedly.
• Disabling security broadly in production by copying local debug config.
• Forgetting to provide controller/view for custom login path.

Summary

Spring Boot showing a login page usually means default Spring Security is active. Fix by defining explicit SecurityFilterChain, removing unneeded security dependency, or configuring dev-only permissive rules carefully. Once security behavior is intentional, routing and authentication flow become predictable.