Change Idempotent to Read-Only

Closes gh-13644

Author: jzheaux

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

@@ -97,13 +97,13 @@ Spring provides two mechanisms to protect against CSRF attacks:
 
 [NOTE]
 ====
-Both protections require that <<Safe Methods Must be Idempotent>>
+Both protections require that <<Safe Methods Must be Read-only>>
 ====
 
-[[csrf-protection-idempotent]]
-=== Safe Methods Must be Idempotent
+[[csrf-protection-read-only]]
+=== Safe Methods Must be Read-only
 
-In order for <<csrf-protection,either protection>> against CSRF to work, the application must ensure that https://tools.ietf.org/html/rfc7231#section-4.2.1["safe" HTTP methods are idempotent].
+In order for <<csrf-protection,either protection>> against CSRF to work, the application must ensure that https://tools.ietf.org/html/rfc7231#section-4.2.1["safe" HTTP methods are read-only].
 This means that requests with the HTTP method `GET`, `HEAD`, `OPTIONS`, and `TRACE` should not change the state of the application.
 
 [[csrf-protection-stp]]
@@ -119,7 +119,7 @@ For example, requiring the actual CSRF token in an HTTP parameter or an HTTP hea
 Requiring the actual CSRF token in a cookie does not work because cookies are automatically included in the HTTP request by the browser.
 
 We can relax the expectations to only require the actual CSRF token for each HTTP request that updates state of the application.
-For that to work, our application must ensure that <<csrf-protection-idempotent,safe HTTP methods are idempotent>>.
+For that to work, our application must ensure that <<csrf-protection-read-only,safe HTTP methods are read-only>>.
 This improves usability since we want to allow linking to our website using links from external sites.
 Additionally, we do not want to include the random token in HTTP GET as this can cause the tokens to be leaked.
 
@@ -190,7 +190,7 @@ Valid values for the `SameSite` attribute are:
 
 * `Strict` - when specified any request coming from the https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1[same-site] will include the cookie.
 Otherwise, the cookie will not be included in the HTTP request.
-* `Lax` - when specified cookies will be sent when coming from the https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1[same-site] or when the request comes from top-level navigations and the <<Safe Methods Must be Idempotent,method is idempotent>>.
+* `Lax` - when specified cookies will be sent when coming from the https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1[same-site] or when the request comes from top-level navigations and the <<Safe Methods Must be Read-only,method is read-only>>.
 Otherwise, the cookie will not be included in the HTTP request.
 
 Let's take a look at how <<csrf-explained,our example>> could be protected using the `SameSite` attribute.

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

@@ -17,7 +17,7 @@ In Spring Security 6, the default is that the lookup of the `CsrfToken` will be
 [NOTE]
 ====
 The `CsrfToken` is needed whenever a request is made with an HTTP verb that would change the state of the application.
-This is covered in detail in xref: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-read-only[Safe Methods Must be Read-only].
 Additionally, it is needed by any request that renders the token to the response, such as a web page with a `<form>` tag that includes a hidden `<input>` for the CSRF token.
 ====
 

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

@@ -7,14 +7,14 @@ This section discusses Spring Security's xref:features/exploits/csrf.adoc#csrf[C
 == Using Spring Security CSRF Protection
 The steps to using Spring Security's CSRF protection are outlined below:
 
-* <<webflux-csrf-idempotent,Use proper HTTP verbs>>
+* <<webflux-csrf-read-only,Use proper HTTP verbs>>
 * <<webflux-csrf-configure,Configure CSRF Protection>>
 * <<webflux-csrf-include,Include the CSRF Token>>
 
-[[webflux-csrf-idempotent]]
+[[webflux-csrf-read-only]]
 === 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: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-read-only[Safe Methods Must be Read-only].
 
 [[webflux-csrf-configure]]
 === Configure CSRF Protection

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

@@ -7,14 +7,14 @@ This section discusses Spring Security's xref:features/exploits/csrf.adoc#csrf[C
 == Using Spring Security CSRF Protection
 The steps to using Spring Security's CSRF protection are outlined below:
 
-* <<servlet-csrf-idempotent,Use proper HTTP verbs>>
+* <<servlet-csrf-read-only,Use proper HTTP verbs>>
 * <<servlet-csrf-configure,Configure CSRF Protection>>
 * <<servlet-csrf-include,Include the CSRF Token>>
 
-[[servlet-csrf-idempotent]]
+[[servlet-csrf-read-only]]
 === 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: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-read-only[Safe Methods Must be Read-only].
 
 [[servlet-csrf-configure]]
 === Configure CSRF Protection