Cloudflare WAF & Turnstile

Allow QA.tech through Cloudflare edge blocking (WAF) and app-embedded Turnstile widgets

Cloudflare can block QA.tech tests in two different ways. They look similar to testers (“something stopped the page”) but are configured in different places and need different fixes.

Two types of Cloudflare blockers

	1. Edge blocking (WAF / firewall)	2. Cloudflare Turnstile (in your app)
What you see	The whole page fails to load—403/1020, “Access denied”, JS challenge, or an interstitial before your HTML	Your app loads, but a small “Verify that you are human” widget blocks a form or action
Who controls it	You, in the Cloudflare dashboard (WAF, firewall rules, Bot Fight Mode, etc.)	You, in your application code—you add the Turnstile widget and validate tokens on your server
Fixed by	WAF custom rules, IP allowlists, verified-bot skips (this page, § WAF)	Test sitekeys, staging config, or server-side bypass—not WAF rules (§ Turnstile)

WAF and firewall rules do not remove an embedded Turnstile widget. If users see the small human-verification box on your login or checkout form, that is application Turnstile—you must change how your app loads or validates Turnstile, not only Cloudflare Security settings.

QA.tech traffic identifies as QATechBot. Use the sections below based on which blocker you hit.

---

WAF and firewall rules

When Cloudflare blocks at the edge, the browser often never receives your app—or gets a Cloudflare error page instead. Configure this in the dashboard under Security → WAF (custom rules, managed rules) and related firewall / bot settings.

On the Free plan, you cannot allow a single verified bot—you can only allow all verified bots at once, or match traffic another way. See Free plan limitations below.

Approaches at the edge

Approach	Best for	Security
Allow all verified bots (cf.client.bot)	Free plan; QA.tech is a Cloudflare-verified bot	High—Cloudflare validates bot IPs
User-Agent + verified bot	Free plan; only QATechBot, when verified	Highest for a single bot
User-Agent only	Allow only QATechBot by name	Lower—User-Agent can be spoofed
IP allowlist	Any plan; works without verified bot status	High when combined with reverse DNS

Free plan limitations

Cloudflare exposes different bot signals by plan:

Signal	Plan	What it does
cf.client.bot	Free	Boolean: true or false. Matches all verified bots or none. You cannot target one bot.
cf.bot_management.verified_bot + cf.verified_bot_category	Enterprise	Target specific bot categories or individual bots.

So on Free you either allow every Cloudflare-verified bot, match QATechBot by User-Agent, or combine User-Agent with cf.client.bot when QA.tech traffic is verified.

See Verifying QATechBot traffic for IP allowlists, reverse DNS, and Web Bot Auth.

Option 1: Allow all verified bots (recommended on Free)

Create a WAF custom rule that skips remaining rules for any Cloudflare-verified bot (including QATechBot when verified):

1. Open WAF custom rules

   In the Cloudflare dashboard, go to Security → WAF → Custom rules.

2. Create the rule

   Expression:

   (cf.client.bot)
   

   Action: Skip → All remaining custom rules

   Place at: First (top of the list).

3. Save and deploy

   Save the rule. Changes usually propagate within a few minutes.

This lets Googlebot, Bingbot, monitoring bots, QATechBot (when verified), and other Cloudflare-verified bots through without hitting your other custom WAF rules.

Option 2: Allow QATechBot by User-Agent only

If you only want to allow traffic that identifies as QATechBot (and accept Free-plan limits on per-bot verification):

1. Create a WAF custom rule

   Expression:

   (http.user_agent contains "QATechBot")
   

   Action: Skip → All remaining custom rules

   Place at: First

User-Agent strings are easy to spoof. Any client can send User-Agent: ...QATechBot.... This is less secure than cf.client.bot, which checks the client against Cloudflare’s verified bot IP data.

The canonical suffix is documented on the QA.tech Bot page.

Option 3: User-Agent and verified bot (best security on Free)

Require both the QATechBot User-Agent and Cloudflare verified-bot status:

1. Create a WAF custom rule

   Expression:

   (http.user_agent contains "QATechBot" and cf.client.bot)
   

   Action: Skip → All remaining custom rules

   Place at: First

The request must claim to be QATechBot and pass Cloudflare’s verified-bot check. Use this when QA.tech egress is recognized as a verified bot.

Enterprise: target specific bots

On Enterprise, you can use Bot Management fields instead of allowing all verified bots:

• cf.bot_management.verified_bot
• cf.verified_bot_category

Use Cloudflare’s bot category documentation to build rules that allow only the categories that include QATechBot, without opening all verified bots.

---

Cloudflare Turnstile in your application

Turnstile is a CAPTCHA-style widget you embed in HTML (login, signup, checkout, etc.). It is not configured with WAF custom rules. QA.tech cannot “skip” production Turnstile from the Cloudflare dashboard alone—you need an application-level strategy.

What testers usually see

• The rest of the page renders normally.
• A compact “Verify that you are human” (or invisible) challenge sits on the form QA.tech is trying to submit.
• Tests fail on submit or timeout waiting for the widget.

What to do instead

Pick one or combine approaches below. All of these are application changes—not Cloudflare dashboard settings.

Bypass Turnstile with a shared header

On staging or other non-production URLs shared with QA.tech, skip rendering and validating Turnstile when a request carries a secret header only your team and QA.tech know.

1. Store a secret in your environment (e.g. CAPTCHA_BYPASS_SECRET)—never commit it or expose it in client-side code.
2. In your app, do not render the widget and skip server-side siteverify when the header matches:

const PRE_SHARED_SECRET = process.env.CAPTCHA_BYPASS_SECRET;

function shouldBypassTurnstile(headers) {
  return headers['x-bypass-captcha'] === PRE_SHARED_SECRET;
}

// When rendering the page
if (shouldBypassTurnstile(request.headers)) {
  // doNotRender() — omit the Turnstile script/widget
} else {
  // render Turnstile as usual
}

// When handling form submit
if (shouldBypassTurnstile(request.headers)) {
  // skip Turnstile siteverify
} else {
  // verify cf-turnstile-response with Cloudflare
}

3. In QA.tech, send the same header on every request—for example via Custom Headers on a device preset:

Header	Value
x-bypass-captcha	Your CAPTCHA_BYPASS_SECRET value

Treat the secret like a password. Use it only on environments where bypass is acceptable, rotate it if leaked, and never enable this check in production unless you fully accept the risk.

Allow QA.tech traffic server-side

If you prefer not to use a shared header, bypass Turnstile only when you can confidently identify QA.tech—for example:

• Request comes from a QA.tech allowlisted IP
• User-Agent contains QATechBot (see QA.tech Bot) and you validate IP or use other checks—not User-Agent alone on production

Apply the same do not render and skip siteverify logic as the header approach, using your server-side detection instead of x-bypass-captcha.

Use Turnstile test keys (non-production)

Cloudflare provides dummy sitekeys and secret keys for automated testing—no real challenge, predictable pass/fail.

1. Pick test credentials

   For example, sitekey 1x00000000000000000000AA with secret 1x0000000000000000000000000000000AA always validates successfully.

2. Wire keys per environment

   In staging, preview, or QA.tech target environments, render the test sitekey in your frontend and validate with the matching test secret on your server. Keep production keys only in production.

Production secret keys reject dummy tokens from test sitekeys. You must use the paired test secret key in the environment where test sitekeys are rendered.

Do not rely on WAF skip rules or verified-bot expressions to clear an in-app Turnstile widget on production keys—those only affect edge security.

---

Related

QA.tech Bot

User-Agent format, IP verification, and Web Bot Auth

IP Access

Allowlist QA.tech egress IPs (helps edge blocking, optional app bypass)

External: Cloudflare WAF custom rules, Verified bots, Turnstile testing