Server-side validation
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.
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.
The siteverify endpoint needs to be passed a secret key that is associated with the sitekey. 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.
POST Parameter | Required/Optional | Description |
---|---|---|
secret | Required | The widget's secret key. The secret key can be found under widget settings in the Cloudflare dashboard under Turnstile. |
response | Required | The response provided by the Turnstile client-side render on your site. |
remoteip | Optional | The visitor's IP address. |
idempotency_key | Optional | The UUID to be associated with the response. |
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.
challenge_ts
is the ISO timestamp for the time the challenge was solved.hostname
is the hostname for which the challenge was served.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 in siteverify.
In case of a validation failure, the response should be similar to the following:
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 code | Description |
---|---|
missing-input-secret | The secret parameter was not passed. |
invalid-input-secret | The secret parameter was invalid, did not exist, or is a testing secret key with a non-testing response. |
missing-input-response | The response parameter (token) was not passed. |
invalid-input-response | The response parameter (token) is invalid or has expired. Most of the time, this means a fake token has been used. If the error persists, contact customer support. |
bad-request | The request was rejected because it was malformed. |
timeout-or-duplicate | The response parameter (token) has already been validated before. This means that the token was issued five minutes ago and is no longer valid, or it was already redeemed. |
internal-error | An internal error happened while validating the response. The request can be retried. |