siteverify

Author: patriciasantaana

src/content/docs/cloudflare-challenges/challenge-types/turnstile.mdx

@@ -13,7 +13,7 @@ Turnstile differs from Challenges Pages in that the Challenge does not pause the
 
 In most cases, nothing further is required from the visitor. However, if necessary, Turnstile may display a simple checkbox that the visitor must click to proceed.
 
-After the Challenge passes, Turnstile issues a clearance token to the visitor that must be validated via the [siteverify API](/turnstile/get-started/server-side-validation/) before completing a sensitive action like login, sign up, or other form submissions. 
+After the Challenge passes, Turnstile issues a clearance token to the visitor that must be validated via the [Siteverify API](/turnstile/get-started/server-side-validation/) before completing a sensitive action like login, sign up, or other form submissions. 
 
 <Render file="siteverify-warning" product="turnstile" />
 
@@ -27,7 +27,7 @@ While there are three types of widgets that you can choose to implement on your
 
 - **Invisible**: The widget is completely invisible from the visitor, but the Challenge still runs in the background.
 
-## implementation
+## Implementation
 
 When you create a widget for your website or application via the Cloudflare dashboard, you will receive a sitekey. 
 

src/content/docs/pages/functions/plugins/turnstile.mdx

@@ -62,4 +62,4 @@ The Plugin is mounted with a single object parameter with the following properti
 
 `onError` is an optional function which takes the Pages Function context object and returns a `Promise` of a `Response`. By default, it will return a human-readable error `Response`.
 
-`context.data.turnstile` will be populated in subsequent Pages Functions (including for the `onError` function) with [the Turnstile siteverify response object](/turnstile/get-started/server-side-validation/).
+`context.data.turnstile` will be populated in subsequent Pages Functions (including for the `onError` function) with [the Turnstile Siteverify response object](/turnstile/get-started/server-side-validation/).

src/content/docs/turnstile/concepts/hostname-management.mdx

@@ -36,7 +36,7 @@ If you already have a zone registered with Cloudflare, you can add hostnames dur
 ## Hostname requirements
 
 :::caution
-Customers enabling [client-side rendering](/turnstile/get-started/client-side-rendering/) must validate their hostnames by looking at the [`hostname`](/turnstile/get-started/server-side-validation/#:~:text=challenge%20was%20solved.-,hostname,-is%20the%20hostname) field in the siteverify response.
+Customers enabling [client-side rendering](/turnstile/get-started/client-side-rendering/) must validate their hostnames by looking at the [`hostname`](/turnstile/get-started/server-side-validation/#:~:text=challenge%20was%20solved.-,hostname,-is%20the%20hostname) field in the Siteverify response.
 :::
 
 When associating hostnames with a widget, follow these requirements:

src/content/docs/turnstile/get-started/client-side-rendering.mdx

@@ -35,7 +35,7 @@ The HTML is scanned for elements that have a `cf-turnstile` class name:
 
 </div>
 
-Once a challenge has been solved, a token is passed to the success callback. This token must be validated against our siteverify endpoint. A token can only be validated once and cannot be consumed twice.
+Once a challenge has been solved, a token is passed to the success callback. This token must be validated against the Siteverify API. A token can only be validated once and cannot be consumed twice.
 
 <Render file="siteverify-warning" />
 
@@ -67,7 +67,7 @@ An invisible input with the name `cf-turnstile-response` is added and will be se
 
 :::note
 
-A form is not protected by having a widget rendered. The corresponding token that is a result of a widget being rendered also needs to be verified using the siteverify API.
+A form is not protected by having a widget rendered. The corresponding token that is a result of a widget being rendered also needs to be verified using the Siteverify API.
 :::
 
 ### Disable implicit rendering

src/content/docs/turnstile/get-started/server-side-validation.mdx

@@ -9,20 +9,20 @@ import { GlossaryTooltip, Render, TabItem, Tabs } from "~/components";
 
 <Render file="siteverify-warning" />
 
-Turnstile needs to be verified using siteverify because it is a front-end widget that creates a token which is cryptographically secured. To ensure that a token is not forged by an attacker or has not been consumed yet, it is necessary to check the validity of a token using Cloudflare's siteverify API.
+Turnstile needs to be verified using Siteverify because it is a front-end widget that creates a token which is cryptographically secured. To ensure that a token is not forged by an attacker or has not been consumed yet, it is necessary to check the validity of a token using Cloudflare's Siteverify API.
 
-You must call the siteverify endpoint to validate the Turnstile widget response from your website’s backend. The widget response must only be considered valid once it has been verified by the siteverify endpoint. The presence of a response alone is not enough to verify it as it does not protect from replay or forgery attacks. In some cases, Turnstile may purposely create invalid responses that are rejected by the siteverify API.
+You must call the Siteverify endpoint to validate the Turnstile widget response from your website’s backend. The widget response must only be considered valid once it has been verified by the Siteverify endpoint. The presence of a response alone is not enough to verify it as it does not protect from replay or forgery attacks. In some cases, Turnstile may purposely create invalid responses that are rejected by the Siteverify API.
 
-Tokens issued to Turnstile using the success callbacks, via explicit or implicit rendering, must be validated using the siteverify endpoint. The siteverify API will only validate a token once. If a token has already been checked, the siteverify API will yield an error on subsequent verification attempts indicating that a token has already been consumed.
+Tokens issued to Turnstile using the success callbacks, via explicit or implicit rendering, must be validated using the Siteverify endpoint. The Siteverify API will only validate a token once. If a token has already been checked, the Siteverify API will yield an error on subsequent verification attempts indicating that a token has already been consumed.
 
 :::note
 
 A Turnstile token can have up to 2048 characters.
 
-It is also valid for 300 seconds before it is rejected by siteverify.
+It is also valid for 300 seconds before it is rejected by Siteverify.
 :::
 
-The siteverify endpoint needs to be passed a <GlossaryTooltip term="secret key">secret key</GlossaryTooltip> that is associated with the <GlossaryTooltip term="sitekey">sitekey</GlossaryTooltip>. The secret key will be provisioned alongside the sitekey when you create a widget. Furthermore, the response needs to be passed to the siteverify endpoint.
+The Siteverify endpoint needs to be passed a <GlossaryTooltip term="secret key">secret key</GlossaryTooltip> that is associated with the <GlossaryTooltip term="sitekey">sitekey</GlossaryTooltip>. The secret key will be provisioned alongside the sitekey when you create a widget. Furthermore, the response needs to be passed to the Siteverify endpoint.
 
 A response may only be validated once. If the same response is presented twice, the second and each subsequent request will generate an error stating that the response has already been consumed. If an application requires to retry failed requests, it must utilize the idempotency functionality. You can do so by providing a UUID as the `idempotency_key` parameter of your `POST` request when initially validating the response and the same UUID with any subsequent request for that response.
 
@@ -244,7 +244,7 @@ async function handlePost(request) {
 The `remoteip` parameter helps to prevent abuse by ensuring the current visitor is the one who received the token. This is currently not strictly validated.
 :::
 
-The siteverify endpoint behaves similar to reCAPTCHA’s or hCaptcha's siteverify endpoint.
+The Siteverify endpoint behaves similar to reCAPTCHA’s or hCaptcha's Siteverify endpoint.
 The API accepts `application/x-www-form-urlencoded` and `application/json` requests, but the response type will always be `application/json`.
 
 It always contains a `success` property, either true or false, indicating whether the operation was successful or not.
@@ -272,7 +272,7 @@ It always contains a `success` property, either true or false, indicating whethe
 - `action` is the customer widget identifier passed to the widget on the client side. This is used to differentiate widgets using the same sitekey in analytics. Its integrity is protected by modifications from an attacker. It is recommended to validate that the action matches an expected value.
 - `cdata` is the customer data passed to the widget on the client side. This can be used by the customer to convey state. It is integrity protected by modifications from an attacker.
 - `error-codes` is a list of errors that occurred.
-- (Enterprise only) `ephemeral_id` returns the [Ephemeral ID](/turnstile/concepts/ephemeral-id/) in siteverify.
+- (Enterprise only) `ephemeral_id` returns the [Ephemeral ID](/turnstile/concepts/ephemeral-id/) in Siteverify.
 
 In case of a validation failure, the response should be similar to the following:
 
@@ -287,7 +287,7 @@ In case of a validation failure, the response should be similar to the following
 
 </div>
 
-A validation error is indicated by having the `success` property set to `false`. A list of error codes is provided to indicate why a response has failed to verify. The response may also contain additional fields based on whether Turnstile siteverify was able to parse the response successfully or unsuccessfully.
+A validation error is indicated by having the `success` property set to `false`. A list of error codes is provided to indicate why a response has failed to verify. The response may also contain additional fields based on whether Turnstile Siteverify was able to parse the response successfully or unsuccessfully.
 
 ## Error codes
 

src/content/docs/turnstile/migration/hcaptcha.mdx

@@ -49,5 +49,5 @@ Turnstile supports:
 
 ## Server-side integration
 
-1. Update the server-side integration by replacing the siteverify URL. Replace: `https://hcaptcha.com/siteverify` with `https://challenges.cloudflare.com/turnstile/v0/siteverify`.
+1. Update the server-side integration by replacing the Siteverify URL. Replace: `https://hcaptcha.com/siteverify` with `https://challenges.cloudflare.com/turnstile/v0/siteverify`.
 2. Replace the `h-captcha-response` input name with `cf-turnstile-response`.

src/content/docs/turnstile/migration/recaptcha.mdx

@@ -49,13 +49,13 @@ Turnstile supports:
 
 ## Server-side integration
 
-Update the server-side integration by replacing the siteverify URL. Replace `https://www.google.com/recaptcha/api/siteverify` with `https://challenges.cloudflare.com/turnstile/v0/siteverify`
+Update the server-side integration by replacing the Siteverify URL. Replace `https://www.google.com/recaptcha/api/siteverify` with `https://challenges.cloudflare.com/turnstile/v0/siteverify`
 
-:::caution[Differences to reCAPTCHA's siteverify]
+:::caution[Differences to reCAPTCHA's Siteverify]
 
 reCAPTCHA supports `GET` requests using query parameters, i.e: `GET /siteverify?response=<response>&secret=<secret>`.
 
-Turnstile's siteverify endpoint does _not_ support this and only accepts `POST` requests with a FormData or JSON body.
+Turnstile's Siteverify endpoint does _not_ support this and only accepts `POST` requests with a FormData or JSON body.
 
 Refer to [server-side validation](/turnstile/get-started/server-side-validation/) for more information.
 :::

src/content/docs/turnstile/troubleshooting/troubleshooting-faqs.mdx

@@ -12,9 +12,9 @@ import { Render } from "~/components"
 
 The Turnstile widget needs to be refreshed to generate a new token. This can be done using the `turnstile.reset` function.
 
-## Can the front end use siteverify?
+## Can the front end use Siteverify?
 
-The siteverify API must not be called by the front end as this may reveal the secret key used to authenticate. An attacker may simply modify the front end to not perform the siteverify check at all, rendering Turnstile ineffective.
+The Siteverify API must not be called by the front end as this may reveal the secret key used to authenticate. An attacker may simply modify the front end to not perform the siteverify check at all, rendering Turnstile ineffective.
 
 
 ## What is challenges.cloudflare.com, and why does my application connect to this origin?

src/content/docs/turnstile/turnstile-analytics/challenge-outcomes.mdx

@@ -11,7 +11,7 @@ When a visitor encounters Turnstile, it assesses whether they are human or bot-l
 
 ## Metrics
 
-A "solved" Turnstile challenge does not automatically confirm the visitor is human. You must [call the siteverify API](#call-siteverify) to validate the token and proceed only if the response returns `success:true`.
+A "solved" Turnstile challenge does not automatically confirm the visitor is human. You must [call the Siteverify API](#call-siteverify) to validate the token and proceed only if the response returns `success:true`.
 
 For example, the challenge outcome values in your analytics may look like this:
 
@@ -25,7 +25,7 @@ For example, the challenge outcome values in your analytics may look like this:
 
 By analyzing these metrics, you can identify trends such as high failure rates in specific regions, device types, or traffic sources, which may indicate bot activity or misconfigurations.
 
-### Call siteverify
+### Call Siteverify
 
 <Render file="siteverify" />
 

src/content/docs/turnstile/turnstile-analytics/token-validation.mdx

@@ -7,18 +7,18 @@ sidebar:
 
 import { Render } from "~/components"
 
-After a visitor successfully completes a Turnstile challenge, a token is generated and validated via the siteverify API. Token validation data provides crucial insights into your security posture.
+After a visitor successfully completes a Turnstile challenge, a token is generated and validated via the Siteverify API. Token validation data provides crucial insights into your security posture.
 
 For example, the token validation values in your analytics may look like this:
 
 ![Token validation example values](~/assets/images/turnstile/token-validation.png "Token validation example")
 
 ## Metrics
 
-- **Siteverify requests**: The total number of requests made to the siteverify API in the given timeframe.
-- **Valid tokens**: The number of siteverify requests with `success:true` responses.
-- **Invalid tokens**: The number of siteverify requests with `success:false` responses.
+- **Siteverify requests**: The total number of requests made to the Siteverify API in the given timeframe.
+- **Valid tokens**: The number of Siteverify requests with `success:true` responses.
+- **Invalid tokens**: The number of Siteverify requests with `success:false` responses.
 
-### Call siteverify
+### Call Siteverify
 
 <Render file="siteverify" />