Introduction

Redirecting HTTP to HTTPS in Spring Boot is easy to describe and easy to get subtly wrong. The right implementation depends on where TLS actually terminates: inside the Spring Boot process, or earlier at a reverse proxy, load balancer, or ingress controller.

Decide Where the Redirect Belongs

In production, the best place to force HTTPS is often the edge layer, not the application itself. If you run behind Nginx, Apache, an AWS load balancer, or Kubernetes ingress, redirecting there is simpler and avoids sending insecure requests deeper into the stack.

Application-level redirect still makes sense when:

• the embedded server terminates TLS directly
• you want app-level enforcement during local or simple deployments
• you need Spring Security rules to require secure channels

The mistake is assuming the application can detect the original scheme correctly without proxy header configuration.

Redirect with Spring Security

If Spring Security is in the stack, the cleanest application-level rule is to require secure channels:

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

With that rule, insecure requests are redirected to HTTPS when the application can correctly determine the incoming scheme.

Configure Forwarded Headers Behind a Proxy

When TLS terminates at a proxy, Spring Boot must trust forwarded scheme information. Otherwise, the app may think every request is plain HTTP or plain HTTPS and generate the wrong redirect behavior.

A common Boot configuration is:

server:
  forward-headers-strategy: framework

That tells the framework to honor forwarded headers such as X-Forwarded-Proto when supported by the deployment environment.

Without this, a reverse proxy setup can cause:

• redirect loops
• wrong absolute URLs
• incorrect security decisions

This is the step many "works on localhost" guides leave out.

Direct TLS in Embedded Tomcat

If the Spring Boot app itself handles TLS, configure the secure connector and optionally add an HTTP connector that redirects to the HTTPS port.

For example, in application.yml:

1server:
2  port: 8443
3  ssl:
4    enabled: true
5    key-store: classpath:keystore.p12
6    key-store-password: changeit
7    key-store-type: PKCS12
8    key-alias: app

And if you want to listen on an insecure port only to redirect it, add a connector:

1import org.apache.catalina.connector.Connector;
2import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory;
3import org.springframework.boot.web.server.WebServerFactoryCustomizer;
4import org.springframework.context.annotation.Bean;
5import org.springframework.context.annotation.Configuration;
6
7@Configuration
8public class TomcatRedirectConfig {
9
10    @Bean
11    WebServerFactoryCustomizer<TomcatServletWebServerFactory> servletContainer() {
12        return factory -> factory.addAdditionalTomcatConnectors(httpConnector());
13    }
14
15    private Connector httpConnector() {
16        Connector connector = new Connector(TomcatServletWebServerFactory.DEFAULT_PROTOCOL);
17        connector.setScheme("http");
18        connector.setPort(8080);
19        connector.setSecure(false);
20        connector.setRedirectPort(8443);
21        return connector;
22    }
23}

That setup is appropriate for smaller deployments where the app owns both ports directly.

Do Not Stop at Redirects

HTTPS migration is not complete when redirects work. You should also think about:

• HSTS headers
• absolute URL generation
• secure cookies
• health checks and internal traffic

Spring Security adds HSTS by default on secure responses, which helps browsers stay on HTTPS after the first secure visit.

Common Pitfalls

The biggest pitfall is configuring redirect logic in the app while TLS actually terminates at a proxy and forwarded headers are not trusted. That usually leads to redirect loops or broken links.

Another mistake is serving both HTTP and HTTPS forever without a redirect strategy, which leaves users on insecure URLs depending on how they arrived.

It is also easy to forget that local development and production may need different setups. A direct embedded-Tomcat solution can be fine locally while production enforcement happens at ingress.

Finally, do not confuse transport security with authentication. HTTPS protects the connection, but it does not replace normal auth and authorization rules.

Summary

• The best HTTP to HTTPS redirect point is often the proxy or ingress layer.
• In Spring Boot, Spring Security can enforce secure channels with requiresSecure().
• Behind proxies, configure forwarded header handling or redirects may break.
• If the app terminates TLS itself, add SSL config and an HTTP redirect connector.
• Treat HSTS, secure cookies, and deployment topology as part of the solution.