Author:
Christopher Frost, Adoption Engineer, Security, Google Cloud
There is an old survival adage that when a grizzly bear charges, you don’t have to outrun the bear—you just have to outrun the person running next to you. In the world of automated bot and fraud defense, that isn't just a quaint saying; it is the fundamental economic reality of how attackers operate.
Cybercriminals don't attack your infrastructure out of ideological malice. They run automated businesses driven by strict Return on Investment (ROI) and conversion metrics. Every residential proxy rotation, CAPTCHA solver API call, and headless browser instance has a concrete line-item cost on their balance sheet. When your implementation raises their cost-per-attempt even slightly above industry baselines, their ROI flips into the red. They stop wasting resources on your endpoints and move on to an easier target.
The problem is that too many organizations approach bot defense as a superficial procurement checkbox. They buy an enterprise challenge service or WAF, flip the toggle to "on," and assume they are safe. But owning a pair of running shoes doesn't help if you tie the laces together before the bear charges. Otherwise, it's a GIGO configuration (garbage in, garbage out).
With 5+ years of analyzing Google Cloud Fraud Defense detection inquiries, we've learned how to help teams avoid common setup issues and build stronger defenses. Let’s look at how we can implement these best practices right from the start.
Here are some caveats, cautions, and tips to architect your defenses so you aren't the slowest runner in the pack using Google Cloud Fraud Defense.
1. The Front-Door Trap: Leaving Secondary APIs Unmonitored
The first architectural mistake we see is focusing 100% of security instrumentation on the primary web login form (login.example.com). Security teams spend weeks fine-tuning scoring rules on the front door, but leave their secondary user-flow APIs—like password resets, GraphQL queries, or mobile backend endpoints—completely unmonitored.
Attackers don't care which door they use. If the front door is locked, they will test every window. We frequently see unmonitored mobile APIs and secondary endpoints targeted by automated credential stuffing and scraping scripts. Because these lightweight API endpoints lack the behavioral telemetry present on the main web UI, attackers can script millions of requests for pennies.
The Fix: The Bot Defense script should be loaded from the user's first interaction with your page or application (such as the home page), and continue through the user-flow. Executes (which are the client side requests for a token from Google, before an assessment can occur) can and should be used at various points along the entire user-flow to capture activity at different stages (3 page form completion? Have an execute with independent action names at every "next" point, execute-only events do not increase costs), not just clustered at the primary login gate. If you are defending an API endpoint, ensure you instrument the full user flow and enforce strict network rate limiting upstream.
2. The Page-Load Execution Trap: Starving Your ML Telemetry
When customers experience degraded detection accuracy, errors, or false-negatives/false-positives from Bot Defense, the root cause is almost universally the same: Loading the script too late or firing grecaptcha.enterprise.execute() too early such as on DOM page load, or before a user's last interaction where we need to make a judgment on.
To understand why this breaks detection, you have to look at the physical mechanics of behavioral risk engines. Bot Defense is looking for the behavioral session to capture human (or bot) activities between the script load and the execute(). If the execute is attempted immediately after the script loads, it's not an accurate portrayal of how the user (or attacker) is actually behaving during the sequence of events.
It’s like asking: “What is more descriptive of an event, a photo or a video?” It's a very similar principle.
Without that diagnostic monitoring window, you strip the telemetry needed to differentiate a human mouse curve from a Puppeteer script. It's not a magic wand; if you starve the model of behavioral telemetry, or if you are daisy-chaining scripts together through outdated third-party wrappers (like unmaintained 3-year-old NPM packages or Tag Manager containers), you create an immediate opportunity for detection failure.
The Fix: Load your enterprise.js script immediately at the start of the <head>, without async or defer which delays signal collection. Bind your execute() calls directly to user intent (like a button click or form submit). Give the risk engine time to observe the session. Review the canonical implementation instructions for instrumenting web pages before deploying.
3. The Blunt Instrument: Indiscriminate Friction vs. Adaptive Policy
Don't treat user friction as an all-or-nothing proposition. Some developers implement mandatory visual CAPTCHAs across 100% of their web traffic. While this might disrupt unsophisticated attackers, it imposes a massive cognitive tax on your genuine customers. In an era of one-click checkout, forcing a human to do games and puzzles is a great way to drive conversion rates into the ground.
A typical Google Cloud Fraud Defense (GCFD) visual challenge isn't inherently bad—it's knowing when to use it. Indiscriminate friction punishes your best customers, while static thresholds let sophisticated residential proxy bots slip straight through.
A better defense can come from Policy-Based Challenge Keys and action-sensitive score thresholding. Bot Defense scores represent the statistical probability that an interacting entity is human (1.0 = 100% human probability, 0.0 = 0% probability). By pairing continuous scoring with adaptive challenge policies, you segment traffic based on real-time risk:
-
High-Confidence Human Traffic (0.7 - 1.0): Allow immediately with zero visual friction. Let genuine users sprint through checkout.
-
Gray-Area / Suspicious Traffic (0.4 - 0.6): Selectively invoke a Policy-Based Challenge Key to verify intent via a step-up challenge or MFA prompt.
-
Known Automated Abuse (0.0 - 0.3): Hard-block automatically by score.
Some actions deserve higher or lower thresholds, and for your most valuable risk points you may not want to offer a visual challenge at all. Reset password or account detail changes may not be something you want to risk deciding over a visual challenge, and instead segment towards an MFA approach or alternative verification as needed.
4. Rigorous Backend Assessment & Telemetry Enrichment
A pristine frontend implementation is completely useless if your server-side token verification is blind or incomplete. When a frontend interaction generates a verification token, your backend service must explicitly evaluate that token via the GCFD API by creating an assessment (projects.assessments.create).
Ensure your backend uses Google Cloud’s CreateAssessment rather than the legacy siteverify endpoint. Only CreateAssessment unlocks full Google Cloud support, platform logging, and advanced telemetry features.
Once calling the correct endpoint, always validate immutable token properties before trusting a score:
-
verify that tokenProperties.valid is true
-
check timestamp freshness to prevent token replay attacks
-
and enforce strict action matching (e.g., ensuring a token generated on contact_form isn't submitted to password_reset).
Just as importantly, your backend request payload must pass vital client context back into the assessment engine. To accurately identify advanced headless browsers, residential proxy rotations, and credential stuffing rings, make sure your backend populates these critical telemetry fields during assessment creation:
-
userIpAddress: Essential for evaluating network IP reputation and identifying routing anomalies.
-
userAgent: Verifies browser identity against observed behavioral telemetry.
-
ja4: Captures TLS handshake fingerprints to expose scripted HTTP clients and browser-evasion tools that spoof standard user agents.
-
userId: Links the assessment to a canonical user account, bridging the gap into authenticated session monitoring.
Starving the backend API of these fields forces the detection engine to make judgments with one hand tied behind its back.
5. Post-Login Session Integrity & Continuous Feedback Loops
Outpacing the other 'runners' means extending your defense beyond anonymous edge requests into authenticated user sessions. Even if an attacker buys valid stolen credentials and routes their script through a clean residential IP, their in-session navigation velocity and device fingerprint switching will inevitably diverge from the real user's historical baseline.
Pass all available UserInfo fields on assessment creation to unlock and evaluate Account Defense labels (such as PROFILE_MATCH vs. SUSPICIOUS_LOGIN_ACTIVITY or CREDENTIAL_STUFFING) on authenticated requests, and your backend can identify behavioral anomalies and terminate compromised sessions before financial damage occurs.
Often missed is closing the feedback loop via the Annotation API (projects.assessments.annotate). Feedback can be given on MFA steps or password correctness without FRAUDULENT or LEGITIMATE labels issued—for example, passing specific MFA reason codes like INITIATED_TWO_FACTOR, PASSED_TWO_FACTOR, or FAILED_TWO_FACTOR directly into the engine.
Alternatively, you can use those authenticity labels (LEGITIMATE / FRAUDULENT) when you are fairly certain (or concrete) about a user. We have layers of judgments built in as safeguards, so being "fairly" certain is worth annotating. Without a continuous feedback loop, machine learning models can't identify when they might be misidentifying a user. Feeding outcomes back into the engine continuously calibrates Account Defense models specifically to your site's traffic patterns, making your defense smarter and more resilient over time.
Summary
Security posture is never absolute; it is entirely relative to the defensive maturity of your peers. By stripping away third-party wrappers, instrumenting multi-point user flows, enriching backend telemetry, and enforcing adaptive risk thresholds, you stop relying on "this should help some" security and start fundamentally bankrupting the attacker's operational model.
