This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Security 7.1.0!

HTTP

All HTTP-based communication, including static resources, should be protected by using TLS.

As a framework, Spring Security does not handle HTTP connections and thus does not provide support for HTTPS directly. However, it does provide a number of features that help with HTTPS usage.

Redirect to HTTPS

When a client uses HTTP, you can configure Spring Security to redirect to HTTPS in both Servlet and WebFlux environments.

Strict Transport Security

Spring Security provides support for Strict Transport Security and enables it by default.

Proxy Server Configuration

When using a proxy server, it is important to ensure that you have configured your application properly. For example, many applications have a load balancer that responds to request for https://example.com/ by forwarding the request to an application server at https://192.168.0.107 Without proper configuration, the application server can not know that the load balancer exists and treats the request as though https://192.168.0.107:8080 was requested by the client.

To fix this, the proxy needs to pass on the details of the original request, and the application needs to be configured to use them. Two kinds of headers are used for this, and it is important to know which of them applies in your deployment:

  • The standard Forwarded header, defined by RFC 7239, which carries the original host, protocol, and client in a single header.

  • The non-standard X-Forwarded-* headers, such as X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-For, which predate RFC 7239.

Most proxies still send the X-Forwarded-* headers rather than the standard Forwarded header, while Spring Framework and servers such as Reactor Netty and Jetty understand both. Do not assume that only one of them is in use.

Both kinds of headers are supplied by the client unless a proxy overwrites them, so an application that trusts them without a trusted proxy in front of it can be made to believe a request arrived over a different host, protocol, or client address than it really did.

For this reason, the proxy at the edge of your network must be configured to remove or overwrite any forwarded headers that arrive from the outside, for both kinds of headers. Dropping only the Forwarded header while passing through X-Forwarded-* (or the reverse) leaves the application open to the same spoofing through the other set. Only headers added by a proxy you control should reach the application.

Once untrusted values are handled at the edge, the application server can be configured to apply the headers. For example, Tomcat uses RemoteIpValve and Jetty uses ForwardedRequestCustomizer. Alternatively, Spring users can use ForwardedHeaderFilter with the Servlet stack or ForwardedHeaderTransformer with the Reactive stack. Both handle the Forwarded header and the X-Forwarded-* headers, and both can be configured to remove the headers instead of applying them, which is useful when the application is not behind a proxy.

Spring Boot users can use the server.forward-headers-strategy property to configure the application. See the Spring Boot documentation for further details.