overview/ -> ../

docs/modules/ROOT/nav.adoc

@@ -1,17 +1,17 @@
 * Overview
-** xref:overview/prerequisites.adoc[Prerequisites]
-** xref:overview/community.adoc[Community]
-** xref:overview/whats-new.adoc[What's New]
-** xref:overview/getting-spring-security.adoc[Getting Spring Security]
-** xref:overview/features/index.adoc[Features]
-*** xref:overview/features/authentication/index.adoc[Authentication]
-**** xref:overview/features/authentication/password-storage.adoc[Password Storage]
-*** xref:overview/features/exploits/index.adoc[Protection Against Exploits]
-**** xref:overview/features/exploits/csrf.adoc[CSRF]
-**** xref:overview/features/exploits/headers.adoc[HTTP Headers]
-**** xref:overview/features/exploits/http.adoc[HTTP Requests]
-** xref:overview/modules.adoc[Project Modules & Dependencies]
-** xref:overview/samples.adoc[Samples]
+** xref:prerequisites.adoc[Prerequisites]
+** xref:community.adoc[Community]
+** xref:whats-new.adoc[What's New]
+** xref:getting-spring-security.adoc[Getting Spring Security]
+** xref:features/index.adoc[Features]
+*** xref:features/authentication/index.adoc[Authentication]
+**** xref:features/authentication/password-storage.adoc[Password Storage]
+*** xref:features/exploits/index.adoc[Protection Against Exploits]
+**** xref:features/exploits/csrf.adoc[CSRF]
+**** xref:features/exploits/headers.adoc[HTTP Headers]
+**** xref:features/exploits/http.adoc[HTTP Requests]
+** xref:modules.adoc[Project Modules & Dependencies]
+** xref:samples.adoc[Samples]
 * xref:servlet/index.adoc[Servlet Applications]
 ** xref:servlet/hello/index.adoc[Hello Spring Security]
 ** xref:servlet/architecture/index.adoc[The Big Picture]

docs/modules/ROOT/pages/community.adoc

@@ -11,7 +11,7 @@ If you need help with Spring Security, we are here to help.
 The following are some of the best ways to get help:
 
 * Read through this documentation.
-* Try one of our many xref:overview/samples.adoc#samples[sample applications].
+* Try one of our many xref:samples.adoc#samples[sample applications].
 * Ask a question on https://stackoverflow.com/questions/tagged/spring-security[https://stackoverflow.com] with the `spring-security` tag.
 * Report bugs and enhancement requests at https://github.com/spring-projects/spring-security/issues
 

docs/modules/ROOT/pages/features/exploits/http.adoc

@@ -14,7 +14,7 @@ When a client uses HTTP, Spring Security can be configured to redirect to HTTPS
 [[http-hsts]]
 == Strict Transport Security
 
-Spring Security provides support for xref:overview/features/exploits/headers.adoc#headers-hsts[Strict Transport Security] and enables it by default.
+Spring Security provides support for xref:features/exploits/headers.adoc#headers-hsts[Strict Transport Security] and enables it by default.
 
 [[http-proxy-server]]
 == Proxy Server Configuration

docs/modules/ROOT/pages/features/exploits/index.adoc

@@ -5,6 +5,6 @@ Spring Security provides protection against common exploits.
 Whenever possible, the protection is enabled by default.
 Below you will find high level description of the various exploits that Spring Security protects against.
 
-* xref:overview/features/exploits/csrf.adoc[CSRF]
-* xref:overview/features/exploits/headers.adoc[HTTP Headers]
-* xref:overview/features/exploits/http.adoc[HTTP Requests]
+* xref:features/exploits/csrf.adoc[CSRF]
+* xref:features/exploits/headers.adoc[HTTP Headers]
+* xref:features/exploits/http.adoc[HTTP Requests]

docs/modules/ROOT/pages/features/index.adoc

@@ -0,0 +1,6 @@
+[[features]]
+= Features
+
+Spring Security provides comprehensive support for xref:features/authentication/index.adoc#authentication[authentication], authorization, and protection against xref:features/exploits/index.adoc#exploits[common exploits].
+It also provides integration with other libraries to simplify its usage.
+

docs/modules/ROOT/pages/getting-spring-security.adoc

@@ -2,7 +2,7 @@
 = Getting Spring Security
 
 This section discusses all you need to know about getting the Spring Security binaries.
-See xref:overview/community.adoc#community-source[Source Code] for how to obtain the source code.
+See xref:community.adoc#community-source[Source Code] for how to obtain the source code.
 
 == Release Numbering
 
@@ -72,7 +72,7 @@ You can do so by adding a Maven property, as the following example shows:
 ----
 ====
 
-If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:overview/modules.adoc#modules[Project Modules and Dependencies].
+If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:modules.adoc#modules[Project Modules and Dependencies].
 
 [[getting-maven-no-boot]]
 === Maven Without Spring Boot
@@ -118,7 +118,7 @@ A minimal Spring Security Maven set of dependencies typically looks like the fol
 ----
 ====
 
-If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:overview/modules.adoc#modules[Project Modules and Dependencies].
+If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:modules.adoc#modules[Project Modules and Dependencies].
 
 Spring Security builds against Spring Framework {spring-core-version} but should generally work with any newer version of Spring Framework 5.x.
 Many users are likely to run afoul of the fact that Spring Security's transitive dependencies resolve Spring Framework {spring-core-version}, which can cause strange classpath problems.
@@ -236,7 +236,7 @@ ext['spring.version']='{spring-core-version}'
 ----
 ====
 
-If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:overview/modules.adoc#modules[Project Modules and Dependencies].
+If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:modules.adoc#modules[Project Modules and Dependencies].
 
 === Gradle Without Spring Boot
 
@@ -274,7 +274,7 @@ dependencies {
 ----
 ====
 
-If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:overview/modules.adoc#modules[Project Modules and Dependencies].
+If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate xref:modules.adoc#modules[Project Modules and Dependencies].
 
 Spring Security builds against Spring Framework {spring-core-version} but should generally work with any newer version of Spring Framework 5.x.
 Many users are likely to run afoul of the fact that Spring Security's transitive dependencies resolve Spring Framework {spring-core-version}, which can cause strange classpath problems.

docs/modules/ROOT/pages/overview/features/index.adoc

@@ -1,6 +0,0 @@
-[[features]]
-= Features
-
-Spring Security provides comprehensive support for xref:overview/features/authentication/index.adoc#authentication[authentication], authorization, and protection against xref:overview/features/exploits/index.adoc#exploits[common exploits].
-It also provides integration with other libraries to simplify its usage.
-

docs/modules/ROOT/pages/reactive/exploits/csrf.adoc

@@ -1,7 +1,7 @@
 [[webflux-csrf]]
 = Cross Site Request Forgery (CSRF) for WebFlux Environments
 
-This section discusses Spring Security's xref:overview/features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)] support for WebFlux environments.
+This section discusses Spring Security's xref:features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)] support for WebFlux environments.
 
 [[webflux-csrf-using]]
 == Using Spring Security CSRF Protection
@@ -14,7 +14,7 @@ The steps to using Spring Security's CSRF protection are outlined below:
 [[webflux-csrf-idempotent]]
 === Use proper HTTP verbs
 The first step to protecting against CSRF attacks is to ensure your website uses proper HTTP verbs.
-This is covered in detail in xref:overview/features/exploits/csrf.adoc#csrf-protection-idempotent[Safe Methods Must be Idempotent].
+This is covered in detail in xref:features/exploits/csrf.adoc#csrf-protection-idempotent[Safe Methods Must be Idempotent].
 
 [[webflux-csrf-configure]]
 === Configure CSRF Protection
@@ -73,7 +73,7 @@ If you do not need the ability to read the cookie with JavaScript directly, it i
 [[webflux-csrf-configure-disable]]
 ==== Disable CSRF Protection
 CSRF protection is enabled by default.
-However, it is simple to disable CSRF protection if it xref:overview/features/exploits/csrf.adoc#csrf-when[makes sense for your application].
+However, it is simple to disable CSRF protection if it xref:features/exploits/csrf.adoc#csrf-when[makes sense for your application].
 
 The Java configuration below will disable CSRF protection.
 
@@ -109,7 +109,7 @@ fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain
 [[webflux-csrf-include]]
 === Include the CSRF Token
 
-In order for the xref:overview/features/exploits/csrf.adoc#csrf-protection-stp[synchronizer token pattern] to protect against CSRF attacks, we must include the actual CSRF token in the HTTP request.
+In order for the xref:features/exploits/csrf.adoc#csrf-protection-stp[synchronizer token pattern] to protect against CSRF attacks, we must include the actual CSRF token in the HTTP request.
 This must be included in a part of the request (i.e. form parameter, HTTP header, etc) that is not automatically included in the HTTP request by the browser.
 
 Spring Security's https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/server/csrf/CsrfWebFilter.html[CsrfWebFilter] exposes a https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfToken.html[Mono<CsrfToken>] as a `ServerWebExchange` attribute named `org.springframework.security.web.server.csrf.CsrfToken`.
@@ -272,19 +272,19 @@ An example of doing this with Thymeleaf is shown below:
 == CSRF Considerations
 There are a few special considerations to consider when implementing protection against CSRF attacks.
 This section discusses those considerations as it pertains to WebFlux environments.
-Refer to xref:overview/features/exploits/csrf.adoc#csrf-considerations[CSRF Considerations] for a more general discussion.
+Refer to xref:features/exploits/csrf.adoc#csrf-considerations[CSRF Considerations] for a more general discussion.
 
 
 [[webflux-considerations-csrf-login]]
 === Logging In
 
-It is important to xref:overview/features/exploits/csrf.adoc#csrf-considerations-login[require CSRF for log in] requests to protect against forging log in attempts.
+It is important to xref:features/exploits/csrf.adoc#csrf-considerations-login[require CSRF for log in] requests to protect against forging log in attempts.
 Spring Security's WebFlux support does this out of the box.
 
 [[webflux-considerations-csrf-logout]]
 === Logging Out
 
-It is important to xref:overview/features/exploits/csrf.adoc#csrf-considerations-logout[require CSRF for log out] requests to protect against forging log out attempts.
+It is important to xref:features/exploits/csrf.adoc#csrf-considerations-logout[require CSRF for log out] requests to protect against forging log out attempts.
 By default Spring Security's `LogoutWebFilter` only processes HTTP post requests.
 This ensures that log out requires a CSRF token and that a malicious user cannot forcibly log out your users.
 
@@ -333,7 +333,7 @@ fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain
 By default Spring Security stores the CSRF token in the `WebSession`.
 This can lead to a situation where the session expires which means there is not an expected CSRF token to validate against.
 
-We've already discussed xref:overview/features/exploits/csrf.adoc#csrf-considerations-login[general solutions] to session timeouts.
+We've already discussed xref:features/exploits/csrf.adoc#csrf-considerations-login[general solutions] to session timeouts.
 This section discusses the specifics of CSRF timeouts as it pertains to the WebFlux support.
 
 It is simple to change storage of the expected CSRF token to be in a cookie.
@@ -344,7 +344,7 @@ For details, refer to the <<webflux-csrf-configure-custom-repository>> section.
 // FIXME: We need a WebFlux multipart body vs action story. WebFlux always has multipart enabled.
 [[webflux-csrf-considerations-multipart]]
 === Multipart (file upload)
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] how protecting multipart requests (file uploads) from CSRF attacks causes a https://en.wikipedia.org/wiki/Chicken_or_the_egg[chicken and the egg] problem.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] how protecting multipart requests (file uploads) from CSRF attacks causes a https://en.wikipedia.org/wiki/Chicken_or_the_egg[chicken and the egg] problem.
 This section discusses how to implement placing the CSRF token in the <<webflux-csrf-considerations-multipart-body,body>> and <<webflux-csrf-considerations-multipart-url,url>> within a WebFlux application.
 
 [NOTE]
@@ -355,7 +355,7 @@ More information about using multipart forms with Spring can be found within the
 [[webflux-csrf-considerations-multipart-body]]
 ==== Place CSRF Token in the Body
 
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] the trade-offs of placing the CSRF token in the body.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] the trade-offs of placing the CSRF token in the body.
 
 In a WebFlux application, this can be configured with the following configuration:
 
@@ -391,7 +391,7 @@ fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain
 [[webflux-csrf-considerations-multipart-url]]
 ==== Include CSRF Token in URL
 
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] the trade-offs of placing the CSRF token in the URL.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] the trade-offs of placing the CSRF token in the URL.
 Since the `CsrfToken` is exposed as an `ServerHttpRequest` <<webflux-csrf-include,request attribute>>, we can use that to create an `action` with the CSRF token in it.
 An example with Thymeleaf is shown below:
 
@@ -407,6 +407,6 @@ An example with Thymeleaf is shown below:
 
 [[webflux-csrf-considerations-override-method]]
 === HiddenHttpMethodFilter
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-override-method[already discussed] overriding the HTTP method.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-override-method[already discussed] overriding the HTTP method.
 
 In a Spring WebFlux application, overriding the HTTP method is done using https://docs.spring.io/spring-framework/docs/5.2.x/javadoc-api/org/springframework/web/filter/reactive/HiddenHttpMethodFilter.html[HiddenHttpMethodFilter].

docs/modules/ROOT/pages/reactive/exploits/headers.adoc

@@ -1,13 +1,13 @@
 [[webflux-headers]]
 = Security HTTP Response Headers
 
-xref:overview/features/exploits/headers.adoc#headers[Security HTTP Response Headers] can be used to increase the security of web applications.
+xref:features/exploits/headers.adoc#headers[Security HTTP Response Headers] can be used to increase the security of web applications.
 This section is dedicated to WebFlux based support for Security HTTP Response Headers.
 
 [[webflux-headers-default]]
 == Default Security Headers
 
-Spring Security provides a xref:overview/features/exploits/headers.adoc#headers-default[default set of Security HTTP Response Headers] to provide secure defaults.
+Spring Security provides a xref:features/exploits/headers.adoc#headers-default[default set of Security HTTP Response Headers] to provide secure defaults.
 While each of these headers are considered best practice, it should be noted that not all clients utilize the headers, so additional testing is encouraged.
 
 You can customize specific headers.
@@ -85,7 +85,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 [[webflux-headers-cache-control]]
 == Cache Control
 
-Spring Security includes xref:overview/features/exploits/headers.adoc#headers-cache-control[Cache Control] headers by default.
+Spring Security includes xref:features/exploits/headers.adoc#headers-cache-control[Cache Control] headers by default.
 
 However, if you actually want to cache specific responses, your application can selectively add them to the https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/http/server/reactive/ServerHttpResponse.html[ServerHttpResponse] to override the header set by Spring Security.
 This is useful to ensure things like CSS, JavaScript, and images are properly cached.
@@ -131,7 +131,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 
 [[webflux-headers-content-type-options]]
 == Content Type Options
-Spring Security includes xref:overview/features/exploits/headers.adoc#headers-content-type-options[Content-Type] headers by default.
+Spring Security includes xref:features/exploits/headers.adoc#headers-content-type-options[Content-Type] headers by default.
 However, you can disable it with:
 
 .Content Type Options Disabled
@@ -169,7 +169,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 
 [[webflux-headers-hsts]]
 == HTTP Strict Transport Security (HSTS)
-Spring Security provides the xref:overview/features/exploits/headers.adoc#headers-hsts[Strict Transport Security] header by default.
+Spring Security provides the xref:features/exploits/headers.adoc#headers-hsts[Strict Transport Security] header by default.
 However, you can customize the results explicitly.
 For example, the following is an example of explicitly providing HSTS:
 
@@ -214,7 +214,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 
 [[webflux-headers-frame-options]]
 == X-Frame-Options
-By default, Spring Security disables rendering within an iframe using xref:overview/features/exploits/headers.adoc#headers-frame-options[X-Frame-Options].
+By default, Spring Security disables rendering within an iframe using xref:features/exploits/headers.adoc#headers-frame-options[X-Frame-Options].
 
 You can customize frame options to use the same origin using the following:
 
@@ -293,7 +293,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 
 [[webflux-headers-csp]]
 == Content Security Policy (CSP)
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-csp[Content Security Policy] by default, because a reasonable default is impossible to know without context of the application.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-csp[Content Security Policy] by default, because a reasonable default is impossible to know without context of the application.
 The web application author must declare the security policy(s) to enforce and/or monitor for the protected resources.
 
 For example, given the following security policy:
@@ -385,7 +385,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 [[webflux-headers-referrer]]
 == Referrer Policy
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-referrer[Referrer Policy] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-referrer[Referrer Policy] headers by default.
 You can enable the Referrer Policy header using configuration as shown below:
 
 .Referrer Policy Configuration
@@ -427,7 +427,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 [[webflux-headers-feature]]
 == Feature Policy
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-feature[Feature Policy] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-feature[Feature Policy] headers by default.
 The following `Feature-Policy` header:
 
 .Feature-Policy Example
@@ -475,7 +475,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 [[webflux-headers-permissions]]
 == Permissions Policy
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-permissions[Permissions Policy] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-permissions[Permissions Policy] headers by default.
 The following `Permissions-Policy` header:
 
 .Permissions-Policy Example
@@ -527,7 +527,7 @@ fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
 [[webflux-headers-clear-site-data]]
 == Clear Site Data
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-clear-site-data[Clear-Site-Data] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-clear-site-data[Clear-Site-Data] headers by default.
 The following Clear-Site-Data header:
 
 .Clear-Site-Data Example

docs/modules/ROOT/pages/reactive/exploits/http.adoc

@@ -1,7 +1,7 @@
 [[webflux-http]]
 = HTTP
 
-All HTTP based communication should be protected xref:overview/features/exploits/http.adoc#http[using TLS].
+All HTTP based communication should be protected xref:features/exploits/http.adoc#http[using TLS].
 
 Below you can find details around WebFlux specific features that assist with HTTPS usage.
 
@@ -84,4 +84,4 @@ Spring Security provides support for xref:servlet/exploits/headers.adoc#servlet-
 [[webflux-http-proxy-server]]
 == Proxy Server Configuration
 
-Spring Security xref:overview/features/exploits/http.adoc#http-proxy-server[integrates with proxy servers].
+Spring Security xref:features/exploits/http.adoc#http-proxy-server[integrates with proxy servers].

docs/modules/ROOT/pages/reactive/oauth2/login.adoc

@@ -42,7 +42,7 @@ TIP: The default redirect URI template is `+{baseUrl}/login/oauth2/code/{registr
 The *_registrationId_* is a unique identifier for the xref:servlet/oauth2/oauth2-client.adoc#oauth2Client-client-registration[ClientRegistration].
 For our example, the `registrationId` is `google`.
 
-IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check xref:overview/features/exploits/http.adoc#http-proxy-server[Proxy Server Configuration] to ensure the application is correctly configured.
+IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check xref:features/exploits/http.adoc#http-proxy-server[Proxy Server Configuration] to ensure the application is correctly configured.
 Also, see the supported xref:servlet/oauth2/oauth2-client.adoc#oauth2Client-auth-code-redirect-uri[ `URI` template variables] for `redirect-uri`.
 
 [[webflux-oauth2-login-sample-config]]

docs/modules/ROOT/pages/servlet/appendix/namespace.adoc

@@ -227,7 +227,7 @@ Optional attribute that specifies the bean name of a `CorsConfigurationSource` t
 === <headers>
 This element allows for configuring additional (security) headers to be send with the response.
 It enables easy configuration for several headers and also allows for setting custom headers through the <<nsa-header,header>> element.
-Additional information, can be found in the xref:overview/features/exploits/headers.adoc#headers[Security Headers] section of the reference.
+Additional information, can be found in the xref:features/exploits/headers.adoc#headers[Security Headers] section of the reference.
 
 ** `Cache-Control`, `Pragma`, and `Expires` - Can be set using the <<nsa-cache-control,cache-control>> element.
 This ensures that the browser does not cache your secured pages.
@@ -674,7 +674,7 @@ if unset, defaults to `anonymousUser`.
 === <csrf>
 This element will add https://en.wikipedia.org/wiki/Cross-site_request_forgery[Cross Site Request Forger (CSRF)] protection to the application.
 It also updates the default RequestCache to only replay "GET" requests upon successful authentication.
-Additional information can be found in the xref:overview/features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)] section of the reference.
+Additional information can be found in the xref:features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)] section of the reference.
 
 
 [[nsa-csrf-parents]]
@@ -2278,7 +2278,7 @@ select username, password, enabled from users where username = ?
 
 [[nsa-password-encoder]]
 === <password-encoder>
-Authentication providers can optionally be configured to use a password encoder as described in the xref:overview/features/authentication/password-storage.adoc#authentication-password-storage[Password Storage].
+Authentication providers can optionally be configured to use a password encoder as described in the xref:features/authentication/password-storage.adoc#authentication-password-storage[Password Storage].
 This will result in the bean being injected with the appropriate `PasswordEncoder` instance.
 
 

docs/modules/ROOT/pages/servlet/authentication/architecture/index.adoc

@@ -5,11 +5,11 @@
 This discussion expands on xref:servlet/architecture/index.adoc#servlet-architecture[Servlet Security: The Big Picture] to describe the main architectural components of Spring Security's used in Servlet authentication.
 If you need concrete flows that explain how these pieces fit together, look at the xref:servlet/authentication/index.adoc#servlet-authentication-mechanisms[Authentication Mechanism] specific sections.
 
-* <<servlet-authentication-securitycontextholder>> - The `SecurityContextHolder` is where Spring Security stores the details of who is xref:overview/features/authentication/index.adoc#authentication[authenticated].
+* <<servlet-authentication-securitycontextholder>> - The `SecurityContextHolder` is where Spring Security stores the details of who is xref:features/authentication/index.adoc#authentication[authenticated].
 * <<servlet-authentication-securitycontext>> - is obtained from the `SecurityContextHolder` and contains the `Authentication` of the currently authenticated user.
 * <<servlet-authentication-authentication>> - Can be the input to `AuthenticationManager` to provide the credentials a user has provided to authenticate or the current user from the `SecurityContext`.
 * <<servlet-authentication-granted-authority>> - An authority that is granted to the principal on the `Authentication` (i.e. roles, scopes, etc.)
-* <<servlet-authentication-authenticationmanager>> -  the API that defines how Spring Security's Filters perform  xref:overview/features/authentication/index.adoc#authentication[authentication].
+* <<servlet-authentication-authenticationmanager>> -  the API that defines how Spring Security's Filters perform  xref:features/authentication/index.adoc#authentication[authentication].
 * <<servlet-authentication-providermanager>> -  the most common implementation of `AuthenticationManager`.
 * <<servlet-authentication-authenticationprovider>> - used by `ProviderManager` to perform a specific type of authentication.
 * <<servlet-authentication-authenticationentrypoint>> - used for requesting credentials from a client (i.e. redirecting to a log in page, sending a `WWW-Authenticate` response, etc.)
@@ -26,7 +26,7 @@ It contains the <<servlet-authentication-securitycontext>>.
 
 image::{figures}/securitycontextholder.png[]
 
-The `SecurityContextHolder` is where Spring Security stores the details of who is xref:overview/features/authentication/index.adoc#authentication[authenticated].
+The `SecurityContextHolder` is where Spring Security stores the details of who is xref:features/authentication/index.adoc#authentication[authenticated].
 Spring Security does not care how the `SecurityContextHolder` is populated.
 If it contains a value, then it is used as the currently authenticated user.
 
@@ -151,7 +151,7 @@ Of course, Spring Security is expressly designed to handle this common requireme
 [[servlet-authentication-authenticationmanager]]
 == AuthenticationManager
 
-{security-api-url}org/springframework/security/authentication/AuthenticationManager.html[`AuthenticationManager`] is the API that defines how Spring Security's Filters perform  xref:overview/features/authentication/index.adoc#authentication[authentication].
+{security-api-url}org/springframework/security/authentication/AuthenticationManager.html[`AuthenticationManager`] is the API that defines how Spring Security's Filters perform  xref:features/authentication/index.adoc#authentication[authentication].
 The <<servlet-authentication-authentication,`Authentication`>> that is returned is then set on the <<servlet-authentication-securitycontextholder>> by the controller (i.e. xref:servlet/architecture/index.adoc#servlet-security-filters[Spring Security's ``Filters``s]) that invoked the `AuthenticationManager`.
 If you are not integrating with __Spring Security's ``Filters``s__ you can set the `SecurityContextHolder` directly and are not required to use an `AuthenticationManager`.
 

docs/modules/ROOT/pages/servlet/authentication/cas.adoc

@@ -92,7 +92,7 @@ The web application side of CAS is made easy due to Spring Security.
 It is assumed you already know the basics of using Spring Security, so these are not covered again below.
 We'll assume a namespace based configuration is being used and add in the CAS beans as required.
 Each section builds upon the previous section.
-A full CAS sample application can be found in the Spring Security xref:overview/samples.adoc#samples[Samples].
+A full CAS sample application can be found in the Spring Security xref:samples.adoc#samples[Samples].
 
 
 [[cas-st]]
@@ -337,7 +337,7 @@ An example configuration is shown below.
 [[cas-pt-client-sample]]
 ==== Calling a Stateless Service Using a Proxy Ticket
 Now that Spring Security obtains PGTs, you can use them to create proxy tickets which can be used to authenticate to a stateless service.
-The CAS xref:overview/samples.adoc#samples[sample application] contains a working example in the `ProxyTicketSampleServlet`.
+The CAS xref:samples.adoc#samples[sample application] contains a working example in the `ProxyTicketSampleServlet`.
 Example code can be found below:
 
 ====

docs/modules/ROOT/pages/servlet/authentication/index.adoc

@@ -1,7 +1,7 @@
 [[servlet-authentication]]
 = Authentication
 
-Spring Security provides comprehensive support for xref:overview/features/authentication/index.adoc#authentication[Authentication].
+Spring Security provides comprehensive support for xref:features/authentication/index.adoc#authentication[Authentication].
 We start by discussing the overall xref:servlet/architecture/index.adoc#servlet-architecture[Servlet Authentication Architecture].
 As you might expect, this section is more abstract describing the architecture without much discussion on how it applies to concrete flows.
 

docs/modules/ROOT/pages/servlet/authentication/unpwd/digest.adoc

@@ -18,7 +18,7 @@ The standard governing HTTP Digest Authentication is defined by https://tools.ie
 Most user agents implement RFC 2617.
 Spring Security's Digest Authentication support is compatible with the "`auth`" quality of protection (`qop`) prescribed by RFC 2617, which also provides backward compatibility with RFC 2069.
 Digest Authentication was seen as a more attractive option if you need to use unencrypted HTTP (i.e. no TLS/HTTPS) and wish to maximise security of the authentication process.
-However, everyone should use xref:overview/features/exploits/http.adoc#http[HTTPS].
+However, everyone should use xref:features/exploits/http.adoc#http[HTTPS].
 
 Central to Digest Authentication is a "nonce".
 This is a value the server generates.
@@ -34,7 +34,7 @@ key:              A private key to prevent modification of the nonce token
 ----
 ====
 
-You will need to ensure you xref:overview/features/authentication/password-storage.adoc#authentication-password-storage-configuration[configure] insecure plain text xref:overview/features/authentication/password-storage.adoc#authentication-password-storage[Password Storage] using `NoOpPasswordEncoder`.
+You will need to ensure you xref:features/authentication/password-storage.adoc#authentication-password-storage-configuration[configure] insecure plain text xref:features/authentication/password-storage.adoc#authentication-password-storage[Password Storage] using `NoOpPasswordEncoder`.
 The following provides an example of configuring Digest Authentication with Java Configuration:
 
 .Digest Authentication

docs/modules/ROOT/pages/servlet/authentication/unpwd/in-memory.adoc

@@ -5,7 +5,7 @@ Spring Security's `InMemoryUserDetailsManager` implements xref:servlet/authentic
 `InMemoryUserDetailsManager` provides management of `UserDetails` by implementing the `UserDetailsManager` interface.
 `UserDetails` based authentication is used by Spring Security when it is configured to xref:servlet/authentication/unpwd/index.adoc#servlet-authentication-unpwd-input[accept a username/password] for authentication.
 
-In this sample we use xref:overview/features/authentication/password-storage.adoc#authentication-password-storage-boot-cli[Spring Boot CLI] to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
+In this sample we use xref:features/authentication/password-storage.adoc#authentication-password-storage-boot-cli[Spring Boot CLI] to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
 
 .InMemoryUserDetailsManager Java Configuration
 ====
@@ -64,7 +64,7 @@ fun users(): UserDetailsService {
 The samples above store the passwords in a secure format, but leave a lot to be desired in terms of getting started experience.
 
 
-In the sample below we leverage xref:overview/features/authentication/password-storage.adoc#authentication-password-storage-dep-getting-started[User.withDefaultPasswordEncoder] to ensure that the password stored in memory is protected.
+In the sample below we leverage xref:features/authentication/password-storage.adoc#authentication-password-storage-dep-getting-started[User.withDefaultPasswordEncoder] to ensure that the password stored in memory is protected.
 However, it does not protect against obtaining the password by decompiling the source code.
 For this reason, `User.withDefaultPasswordEncoder` should only be used for "getting started" and is not intended for production.
 
@@ -114,7 +114,7 @@ fun users(): UserDetailsService {
 ====
 
 There is no simple way to use `User.withDefaultPasswordEncoder` with XML based configuration.
-For demos or just getting started, you can choose to prefix the password with `+{noop}+` to indicate xref:overview/features/authentication/password-storage.adoc#authentication-password-storage-dpe-format[no encoding should be used].
+For demos or just getting started, you can choose to prefix the password with `+{noop}+` to indicate xref:features/authentication/password-storage.adoc#authentication-password-storage-dpe-format[no encoding should be used].
 
 .<user-service> `+{noop}+` XML Configuration
 ====

docs/modules/ROOT/pages/servlet/authentication/unpwd/jdbc.adoc

@@ -147,8 +147,8 @@ In a production environment, you will want to ensure you setup a connection to a
 [[servlet-authentication-jdbc-bean]]
 == JdbcUserDetailsManager Bean
 
-In this sample we use xref:overview/features/authentication/password-storage.adoc#authentication-password-storage-boot-cli[Spring Boot CLI] to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
-See the xref:overview/features/authentication/password-storage.adoc#authentication-password-storage[PasswordEncoder] section for more details about how to store passwords.
+In this sample we use xref:features/authentication/password-storage.adoc#authentication-password-storage-boot-cli[Spring Boot CLI] to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
+See the xref:features/authentication/password-storage.adoc#authentication-password-storage[PasswordEncoder] section for more details about how to store passwords.
 
 .JdbcUserDetailsManager
 ====

docs/modules/ROOT/pages/servlet/authentication/unpwd/password-encoder.adoc

@@ -1,5 +1,5 @@
 [[servlet-authentication-password-storage]]
 = PasswordEncoder
 
-Spring Security's servlet support storing passwords securely by integrating with xref:overview/features/authentication/password-storage.adoc#authentication-password-storage[`PasswordEncoder`].
-Customizing the `PasswordEncoder` implementation used by Spring Security can be done by xref:overview/features/authentication/password-storage.adoc#authentication-password-storage-configuration[exposing a `PasswordEncoder` Bean].
+Spring Security's servlet support storing passwords securely by integrating with xref:features/authentication/password-storage.adoc#authentication-password-storage[`PasswordEncoder`].
+Customizing the `PasswordEncoder` implementation used by Spring Security can be done by xref:features/authentication/password-storage.adoc#authentication-password-storage-configuration[exposing a `PasswordEncoder` Bean].

docs/modules/ROOT/pages/servlet/exploits/csrf.adoc

@@ -1,7 +1,7 @@
 [[servlet-csrf]]
 = Cross Site Request Forgery (CSRF) for Servlet Environments
 
-This section discusses Spring Security's xref:overview/features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)] support for servlet environments.
+This section discusses Spring Security's xref:features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)] support for servlet environments.
 
 [[servlet-csrf-using]]
 == Using Spring Security CSRF Protection
@@ -14,7 +14,7 @@ The steps to using Spring Security's CSRF protection are outlined below:
 [[servlet-csrf-idempotent]]
 === Use proper HTTP verbs
 The first step to protecting against CSRF attacks is to ensure your website uses proper HTTP verbs.
-This is covered in detail in xref:overview/features/exploits/csrf.adoc#csrf-protection-idempotent[Safe Methods Must be Idempotent].
+This is covered in detail in xref:features/exploits/csrf.adoc#csrf-protection-idempotent[Safe Methods Must be Idempotent].
 
 [[servlet-csrf-configure]]
 === Configure CSRF Protection
@@ -105,7 +105,7 @@ If you do not need the ability to read the cookie with JavaScript directly, it i
 [[servlet-csrf-configure-disable]]
 ==== Disable CSRF Protection
 CSRF protection is enabled by default.
-However, it is simple to disable CSRF protection if it xref:overview/features/exploits/csrf.adoc#csrf-when[makes sense for your application].
+However, it is simple to disable CSRF protection if it xref:features/exploits/csrf.adoc#csrf-when[makes sense for your application].
 
 The XML configuration below will disable CSRF protection.
 
@@ -162,7 +162,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-csrf-include]]
 === Include the CSRF Token
 
-In order for the xref:overview/features/exploits/csrf.adoc#csrf-protection-stp[synchronizer token pattern] to protect against CSRF attacks, we must include the actual CSRF token in the HTTP request.
+In order for the xref:features/exploits/csrf.adoc#csrf-protection-stp[synchronizer token pattern] to protect against CSRF attacks, we must include the actual CSRF token in the HTTP request.
 This must be included in a part of the request (i.e. form parameter, HTTP header, etc) that is not automatically included in the HTTP request by the browser.
 
 Spring Security's https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfFilter.html[CsrfFilter] exposes a https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfToken.html[CsrfToken] as an `HttpServletRequest` attribute named `_csrf`.
@@ -301,19 +301,19 @@ An example of doing this with a JSP is shown below:
 == CSRF Considerations
 There are a few special considerations to consider when implementing protection against CSRF attacks.
 This section discusses those considerations as it pertains to servlet environments.
-Refer to xref:overview/features/exploits/csrf.adoc#csrf-considerations[CSRF Considerations] for a more general discussion.
+Refer to xref:features/exploits/csrf.adoc#csrf-considerations[CSRF Considerations] for a more general discussion.
 
 
 [[servlet-considerations-csrf-login]]
 === Logging In
 
-It is important to xref:overview/features/exploits/csrf.adoc#csrf-considerations-login[require CSRF for log in] requests to protect against forging log in attempts.
+It is important to xref:features/exploits/csrf.adoc#csrf-considerations-login[require CSRF for log in] requests to protect against forging log in attempts.
 Spring Security's servlet support does this out of the box.
 
 [[servlet-considerations-csrf-logout]]
 === Logging Out
 
-It is important to xref:overview/features/exploits/csrf.adoc#csrf-considerations-logout[require CSRF for log out] requests to protect against forging log out attempts.
+It is important to xref:features/exploits/csrf.adoc#csrf-considerations-logout[require CSRF for log out] requests to protect against forging log out attempts.
 If CSRF protection is enabled (default), Spring Security's `LogoutFilter` to only process HTTP POST.
 This ensures that log out requires a CSRF token and that a malicious user cannot forcibly log out your users.
 
@@ -367,7 +367,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 By default Spring Security stores the CSRF token in the `HttpSession`.
 This can lead to a situation where the session expires which means there is not an expected CSRF token to validate against.
 
-We've already discussed xref:overview/features/exploits/csrf.adoc#csrf-considerations-login[general solutions] to session timeouts.
+We've already discussed xref:features/exploits/csrf.adoc#csrf-considerations-login[general solutions] to session timeouts.
 This section discusses the specifics of CSRF timeouts as it pertains to the servlet support.
 
 It is simple to change storage of the expected CSRF token to be in a cookie.
@@ -381,7 +381,7 @@ For an example of how to customize the `AccessDeniedHandler` refer to the provid
 
 [[servlet-csrf-considerations-multipart]]
 === Multipart (file upload)
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] how protecting multipart requests (file uploads) from CSRF attacks causes a https://en.wikipedia.org/wiki/Chicken_or_the_egg[chicken and the egg] problem.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-multipart[already discussed] how protecting multipart requests (file uploads) from CSRF attacks causes a https://en.wikipedia.org/wiki/Chicken_or_the_egg[chicken and the egg] problem.
 This section discusses how to implement placing the CSRF token in the <<servlet-csrf-considerations-multipart-body,body>> and <<servlet-csrf-considerations-multipart-url,url>> within a servlet application.
 
 [NOTE]
@@ -392,7 +392,7 @@ More information about using multipart forms with Spring can be found within the
 [[servlet-csrf-considerations-multipart-body]]
 ==== Place CSRF Token in the Body
 
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-multipart-body[already discussed] the tradeoffs of placing the CSRF token in the body.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-multipart-body[already discussed] the tradeoffs of placing the CSRF token in the body.
 In this section we will discuss how to configure Spring Security to read the CSRF from the body.
 
 In order to read the CSRF token from the body, the `MultipartFilter` is specified before the Spring Security filter.
@@ -473,7 +473,7 @@ An example with a jsp is shown below
 
 [[servlet-csrf-considerations-override-method]]
 === HiddenHttpMethodFilter
-We have xref:overview/features/exploits/csrf.adoc#csrf-considerations-multipart-body[already discussed] the trade-offs of placing the CSRF token in the body.
+We have xref:features/exploits/csrf.adoc#csrf-considerations-multipart-body[already discussed] the trade-offs of placing the CSRF token in the body.
 
 In Spring's Servlet support, overriding the HTTP method is done using https://docs.spring.io/spring-framework/docs/5.2.x/javadoc-api/org/springframework/web/filter/reactive/HiddenHttpMethodFilter.html[HiddenHttpMethodFilter].
 More information can be found in https://docs.spring.io/spring/docs/5.2.x/spring-framework-reference/web.html#mvc-rest-method-conversion[HTTP Method Conversion] section of the reference documentation.

docs/modules/ROOT/pages/servlet/exploits/headers.adoc

@@ -1,13 +1,13 @@
 [[servlet-headers]]
 = Security HTTP Response Headers
 
-xref:overview/features/exploits/headers.adoc#headers[Security HTTP Response Headers] can be used to increase the security of web applications.
+xref:features/exploits/headers.adoc#headers[Security HTTP Response Headers] can be used to increase the security of web applications.
 This section is dedicated to servlet based support for Security HTTP Response Headers.
 
 [[servlet-headers-default]]
 == Default Security Headers
 
-Spring Security provides a xref:overview/features/exploits/headers.adoc#headers-default[default set of Security HTTP Response Headers] to provide secure defaults.
+Spring Security provides a xref:features/exploits/headers.adoc#headers-default[default set of Security HTTP Response Headers] to provide secure defaults.
 While each of these headers are considered best practice, it should be noted that not all clients utilize the headers, so additional testing is encouraged.
 
 You can customize specific headers.
@@ -71,7 +71,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 If you do not want the defaults to be added and want explicit control over what should be used, you can disable the defaults.
 An example is provided below:
 
-If you are using Spring Security's Configuration the following will only add xref:overview/features/exploits/headers.adoc#headers-cache-control[Cache Control].
+If you are using Spring Security's Configuration the following will only add xref:features/exploits/headers.adoc#headers-cache-control[Cache Control].
 
 .Customize Cache Control Headers
 ====
@@ -177,7 +177,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-cache-control]]
 == Cache Control
 
-Spring Security includes xref:overview/features/exploits/headers.adoc#headers-cache-control[Cache Control] headers by default.
+Spring Security includes xref:features/exploits/headers.adoc#headers-cache-control[Cache Control] headers by default.
 
 However, if you actually want to cache specific responses, your application can selectively invoke https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setHeader(java.lang.String,java.lang.String)[HttpServletResponse.setHeader(String,String)] to override the header set by Spring Security.
 This is useful to ensure things like CSS, JavaScript, and images are properly cached.
@@ -242,7 +242,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-content-type-options]]
 == Content Type Options
 
-Spring Security includes xref:overview/features/exploits/headers.adoc#headers-content-type-options[Content-Type] headers by default.
+Spring Security includes xref:features/exploits/headers.adoc#headers-content-type-options[Content-Type] headers by default.
 However, you can disable it with:
 
 .Content Type Options Disabled
@@ -300,7 +300,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-hsts]]
 == HTTP Strict Transport Security (HSTS)
 
-Spring Security provides the xref:overview/features/exploits/headers.adoc#headers-hsts[Strict Transport Security] header by default.
+Spring Security provides the xref:features/exploits/headers.adoc#headers-hsts[Strict Transport Security] header by default.
 However, you can customize the results explicitly.
 For example, the following is an example of explicitly providing HSTS:
 
@@ -366,7 +366,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 
 [[servlet-headers-hpkp]]
 == HTTP Public Key Pinning (HPKP)
-For passivity reasons, Spring Security provides servlet support for xref:overview/features/exploits/headers.adoc#headers-hpkp[HTTP Public Key Pinning] but it is xref:overview/features/exploits/headers.adoc#headers-hpkp-deprecated[no longer recommended].
+For passivity reasons, Spring Security provides servlet support for xref:features/exploits/headers.adoc#headers-hpkp[HTTP Public Key Pinning] but it is xref:features/exploits/headers.adoc#headers-hpkp-deprecated[no longer recommended].
 
 You can enable HPKP headers with the following Configuration:
 
@@ -437,7 +437,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-frame-options]]
 == X-Frame-Options
 
-By default, Spring Security disables rendering within an iframe using xref:overview/features/exploits/headers.adoc#headers-frame-options[X-Frame-Options].
+By default, Spring Security disables rendering within an iframe using xref:features/exploits/headers.adoc#headers-frame-options[X-Frame-Options].
 
 You can customize frame options to use the same origin within a Configuration using the following:
 
@@ -560,7 +560,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-csp]]
 == Content Security Policy (CSP)
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-csp[Content Security Policy] by default, because a reasonable default is impossible to know without context of the application.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-csp[Content Security Policy] by default, because a reasonable default is impossible to know without context of the application.
 The web application author must declare the security policy(s) to enforce and/or monitor for the protected resources.
 
 For example, given the following security policy:
@@ -693,7 +693,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-referrer]]
 == Referrer Policy
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-referrer[Referrer Policy] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-referrer[Referrer Policy] headers by default.
 You can enable the Referrer Policy header using the configuration as shown below:
 
 .Referrer Policy
@@ -753,7 +753,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-feature]]
 == Feature Policy
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-feature[Feature Policy] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-feature[Feature Policy] headers by default.
 The following `Feature-Policy` header:
 
 .Feature-Policy Example
@@ -819,7 +819,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-permissions]]
 == Permissions Policy
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-permissions[Permissions Policy] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-permissions[Permissions Policy] headers by default.
 The following `Permissions-Policy` header:
 
 .Permissions-Policy Example
@@ -889,7 +889,7 @@ class SecurityConfig : WebSecurityConfigurerAdapter() {
 [[servlet-headers-clear-site-data]]
 == Clear Site Data
 
-Spring Security does not add xref:overview/features/exploits/headers.adoc#headers-clear-site-data[Clear-Site-Data] headers by default.
+Spring Security does not add xref:features/exploits/headers.adoc#headers-clear-site-data[Clear-Site-Data] headers by default.
 The following Clear-Site-Data header:
 
 .Clear-Site-Data Example

docs/modules/ROOT/pages/servlet/exploits/http.adoc

@@ -1,7 +1,7 @@
 [[servlet-http]]
 = HTTP
 
-All HTTP based communication should be protected xref:overview/features/exploits/http.adoc#http[using TLS].
+All HTTP based communication should be protected xref:features/exploits/http.adoc#http[using TLS].
 
 Below you can find details around Servlet specific features that assist with HTTPS usage.
 
@@ -74,4 +74,4 @@ Spring Security provides support for xref:servlet/exploits/headers.adoc#servlet-
 [[servlet-http-proxy-server]]
 == Proxy Server Configuration
 
-Spring Security xref:overview/features/exploits/http.adoc#http-proxy-server[integrates with proxy servers].
+Spring Security xref:features/exploits/http.adoc#http-proxy-server[integrates with proxy servers].

docs/modules/ROOT/pages/servlet/exploits/index.adoc

@@ -1,7 +1,7 @@
 [[servlet-exploits]]
 = Protection Against Exploits
 
-This section discusses Servlet specific support for xref:overview/features/exploits/index.adoc#exploits[Spring Security's protection against common exploits].
+This section discusses Servlet specific support for xref:features/exploits/index.adoc#exploits[Spring Security's protection against common exploits].
 
 * xref:servlet/exploits/csrf.adoc[]
 * xref:servlet/exploits/headers.adoc[]

docs/modules/ROOT/pages/servlet/hello/index.adoc

@@ -12,7 +12,7 @@ For your convenience, you can download a minimal Spring Boot + Spring Security a
 [[servlet-hello-dependencies]]
 == Updating Dependencies
 
-The only step you need to do is update the dependencies by using xref:overview/getting-spring-security.adoc#getting-maven-boot[Maven] or xref:overview/getting-spring-security.adoc#getting-gradle-boot[Gradle].
+The only step you need to do is update the dependencies by using xref:getting-spring-security.adoc#getting-maven-boot[Maven] or xref:getting-spring-security.adoc#getting-gradle-boot[Gradle].
 
 [[servlet-hello-starting]]
 == Starting Hello Spring Security Boot

docs/modules/ROOT/pages/servlet/integrations/websocket.adoc

@@ -246,7 +246,7 @@ Spring Security adds an additional layer of protection to provide https://en.wik
 [[websocket-sameorigin-csrf]]
 === Adding CSRF to Stomp Headers
 
-By default Spring Security requires the xref:overview/features/exploits/csrf.adoc#csrf[CSRF token] in any CONNECT message type.
+By default Spring Security requires the xref:features/exploits/csrf.adoc#csrf[CSRF token] in any CONNECT message type.
 This ensures that only a site that has access to the CSRF token can connect.
 Since only the *Same Origin* can access the CSRF token, external domains are not allowed to make a connection.
 
@@ -357,7 +357,7 @@ When using the fallback options we need to relax a few security constraints to a
 === SockJS & frame-options
 
 SockJS may use an https://github.com/sockjs/sockjs-client/tree/v0.3.4[transport that leverages an iframe].
-By default Spring Security will xref:overview/features/exploits/headers.adoc#headers-frame-options[deny] the site from being framed to prevent Clickjacking attacks.
+By default Spring Security will xref:features/exploits/headers.adoc#headers-frame-options[deny] the site from being framed to prevent Clickjacking attacks.
 To allow SockJS frame based transports to work, we need to configure Spring Security to allow the same origin to frame the content.
 
 You can customize X-Frame-Options with the xref:servlet/appendix/namespace.adoc#nsa-frame-options[frame-options] element.

docs/modules/ROOT/pages/servlet/oauth2/oauth2-client.adoc

@@ -702,7 +702,7 @@ spring:
 [NOTE]
 `+{baseUrl}+` resolves to `+{baseScheme}://{baseHost}{basePort}{basePath}+`
 
-Configuring the `redirect-uri` with `URI` template variables is especially useful when the OAuth 2.0 Client is running behind a xref:overview/features/exploits/http.adoc#http-proxy-server[Proxy Server].
+Configuring the `redirect-uri` with `URI` template variables is especially useful when the OAuth 2.0 Client is running behind a xref:features/exploits/http.adoc#http-proxy-server[Proxy Server].
 This ensures that the `X-Forwarded-*` headers are used when expanding the `redirect-uri`.
 
 ==== Customizing the Authorization Request

docs/modules/ROOT/pages/servlet/oauth2/oauth2-login.adoc

@@ -42,7 +42,7 @@ In the "Set a redirect URI" sub-section, ensure that the *Authorized redirect UR
 TIP: The default redirect URI template is `+{baseUrl}/login/oauth2/code/{registrationId}+`.
 The *_registrationId_* is a unique identifier for the xref:servlet/oauth2/oauth2-client.adoc#oauth2Client-client-registration[ClientRegistration].
 
-IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check xref:overview/features/exploits/http.adoc#http-proxy-server[Proxy Server Configuration] to ensure the application is correctly configured.
+IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check xref:features/exploits/http.adoc#http-proxy-server[Proxy Server Configuration] to ensure the application is correctly configured.
 Also, see the supported xref:servlet/oauth2/oauth2-client.adoc#oauth2Client-auth-code-redirect-uri[ `URI` template variables] for `redirect-uri`.