Do You Still Need Dregs If You Already Use Cloudflare or a WAF?

You turned Cloudflare on.

The overnight signup flood stopped. The scraper that had been paging through the app started collecting challenge pages instead of user rows. Bot Fight Mode, or Bot Management on an Enterprise zone, did the job it was sold to do. It looked at each request and kept the obvious machines out.

Then the same fellow opened his fifth free trial in an ordinary browser. A new disposable address, a Turnstile token that validated, no challenge page. Cloudflare was right. He is not a bot.

He is also not a customer. Most of what actually costs a SaaS money is patient and human-shaped, and a request check has no memory of the accounts behind it. Dregs is one judgment layer for that second question. It scores the account over time, behind the edge you already run.

What Cloudflare Bot Management Catches Well

The edge classifies the request before your origin has to handle it. On Cloudflare that is three different products, not one switch. The description below was checked against Cloudflare's public docs on October 26, 2026.

Bot scores, verified bots, and JavaScript detections

Bot Management is a paid Enterprise add-on. Cloudflare's docs describe a bot score from 1 to 99 on every scored request. A score of 1 means Cloudflare is quite sure the request was automated. A score of 99 means it is quite sure the request came from a person. The same docs group 1 as automated, 2 through 29 as likely automated, and 30 through 99 as likely human. You write WAF custom rules or Workers against that score, so a login path can challenge a low score while a public docs page does not. Granular scores are an Enterprise Bot Management feature. Without that add-on, Cloudflare's docs say you get bot groupings in Bot Analytics rather than the 1 to 99 score. Pro plans and above can also see those groupings under Security, then Bots.

Verified bots are labeled on their own: crawlers and agents Cloudflare has checked, mainly with reverse DNS, and also with ASN blocks, public lists, and its own data. The usual WAF templates exclude cf.bot_management.verified_bot so a block aimed at definite bots does not also hit a search crawler. That allowlist is the right place to decide what happens to useful automation. A low Humanity score later, on an account, is a different decision.

JavaScript detections are a lightweight script Cloudflare can inject into HTML. They look for headless browsers and other automation, and they set cf.bot_management.js_detection.passed for a WAF rule to read. On Bot Management the injection is optional. On Bot Fight Mode it is on, and Cloudflare's docs say it cannot be turned off. A missing or empty User-Agent is scored 1 by the Enterprise heuristics engine. Cloudflare documents that as expected, and as a common false positive when a corporate proxy strips the header. The cf.bot_management.corporate_proxy field exists so a rule can exempt that traffic instead of blocking the office.

Cloudflare Bot Fight Mode

Bot Fight Mode is the free product. It looks for traffic that matches known bot patterns and issues a computationally expensive challenge, which raises the cost of sending those requests. It covers the whole domain. It does not run on the Ruleset Engine, so a WAF custom rule cannot skip it, and you cannot aim it at one path. Cloudflare warns that it may challenge API and mobile app traffic.

Super Bot Fight Mode is included on Pro, Business, and Enterprise. It uses the same underlying detection, adds an action per bot category (definitely automated, likely automated, verified bots), and can be skipped: a WAF custom rule with the Skip action runs first and lets the request pass that phase. It is still domain-wide. Path-by-path scores, and rules you write yourself against a number, are the Enterprise Bot Management add-on.

For a flood of the same scraper, this is the layer that earns its keep. Raw volume still belongs with the WAF, rate limiting, and HTTP DDoS controls sitting next to it. Bot Fight Mode is the bot classification, not a substitute for those.

Turnstile and managed challenges

Cloudflare issues challenges in more than one shape. The challenges documentation separates an interstitial challenge page (WAF custom rules, Bot Fight Mode, Super Bot Fight Mode, Under Attack Mode) from JavaScript detections, which run without pausing the visitor, and from Turnstile, which is a widget on the page.

Turnstile runs without sending the visitor through Cloudflare's CDN, so it works on a site that terminates somewhere else. It starts with small non-interactive checks: proof of work, proof of space, web API probes, browser quirks, and human behavior signals. Managed mode, the recommended widget, shows a checkbox only when Cloudflare wants more proof, and that checkbox is not an image puzzle. Your server still has to validate the token with Siteverify. Cloudflare's get-started guide says tokens expire after 300 seconds and can be validated once. Skipping that call leaves the widget as decoration.

Known bad addresses

Bot Management's heuristics match requests against a database of known malicious fingerprints. Separately, Cloudflare evaluates IP Access rules before Bot Fight Mode: when an IP Access rule matches the request first, Bot Fight Mode does not also run. Source addresses you already want to refuse belong in an IP Access rule or a WAF custom rule. The edge can refuse that source before your application ever sees the request.

What a Passed Request Still Hides

A bot score describes one request. A challenge describes one solve. Neither one is a ledger of accounts. The abuse that remains is the kind a careful operator produces on purpose.

The freeloader on trial number five is the ordinary case. Real Chrome, real typing, a fresh disposable address, a bot score in the band Cloudflare calls likely human. Nothing failed. The pattern shows up only when this account is connected to the last four. Free trial abuse is that pattern.

Farmed accounts pass for the same reason. A challenge that asks "is a person operating this browser" is answered by a phone farm, or by a row of ordinary browsers with someone sitting behind them. Solver farms are a toll on image puzzles. A widget with no image still meets a human hand, which is what it was built to accept. CAPTCHA alternatives walks through why a passed token is a weak receipt.

Ban evasion is the same person after you already said no. New email, same browser, same habits. The new request is clean. The history is not. See ban evasion.

Promo codes and referral bounties are often collected by people, not scripts. The enterprising operator refers a crowd of one, or redeems a welcome offer until the ledger notices. Each request is a normal signup. The scheme is the set of them. See referral fraud and promo abuse.

Multi accounting is the general form. Several accounts, one person, each signup plausible on its own. Email verification, a challenge, and a WAF rule that looks at this request will all agree the visitor may come in. The link is across accounts: a shared device, overlapping identity data, a routine that repeats. That is duplicate accounts, and it is why a user table can fill with fake signups on a zone where Bot Fight Mode is already on and working.

How the Edge and the Account Fit Together

Keep the edge. Add a judgment layer behind it. One signup travels through both, in this order. The same order holds when the edge is AWS WAF, Fastly, or Akamai instead of Cloudflare: the product in front of the origin still judges the request.

1. Your hostname. The CDN or WAF terminates TLS and applies rate limits, IP rules, and managed rules. Known bad sources die here.
2. Bot management. The request gets a score or a category. Low scores can be challenged or blocked. Verified bots can be allowed on purpose.
3. A challenge, if you still want one. Turnstile, or a managed challenge, on the few routes where a false allow is expensive. Not on every page view.
4. Your application. Whoever got through can create an account. This is the first moment an identity exists.
5. Dregs. The browser tracker, loaded from dregs.com, reports the session directly. Your server sends the signup with the same user id. Scores update moments after new activity.
6. Your decision. Badges, escalations, and webhooks tell the app. Dregs does not block the request. The app refuses, restricts, or reviews.

Dregs scores every identity on four dimensions from the events you send:

• Humanity: whether the device and timing look like a person or like automation.
• Authenticity: whether the identity data looks real or fabricated.
• Uniqueness: whether this account shares a device or identity with others.
• Behavior: whether usage looks like a customer's, or like a script running a routine.

Each score opens into its observations, so you can see exactly why an account was marked down before anyone acts. Custom rules and lists turn those scores into badges and escalations. Read scores at a decision point (granting trial credits, paying a referral, raising a limit), not in the same instant as the signup call. Scoring is asynchronous. A single low number is a reason to look, not an automatic ban: privacy-conscious people on unusual browsers produce false positives if you treat one dip as a verdict. Escalations put borderline suspicious accounts in front of a person, which keeps those false positives off real customers and means less manual review for everyone else.

const scores = await dregs.identities.scores(user.id);

if (scores.uniqueness !== null && scores.uniqueness < 40) {
  await holdTrialCredits(user.id); // your threshold, not a fixed product rule
}

The bands on the scoring page are a guide for that threshold. For anything you do not want to poll, a badge rule with an apply delay and a webhook is the path. Escalations cover the cases a rule should not close alone.

AWS WAF Bot Control

AWS WAF Bot Control is the same kind of layer on AWS. Checked October 26, 2026. AWS describes it as a way to monitor, block, or rate limit bots such as scrapers, scanners, crawlers, status monitors, and search engines. It is a managed rule group, AWSManagedRulesBotControlRuleSet, and AWS charges additional fees for it on top of WAF.

AWS documents two levels. Common protection detects bots that identify themselves (user agent, IP address, and other request traits), verifies that bots claiming to be a known organization actually come from that organization, and lets you control categories such as search crawlers. It does not detect bots that hide their identity, and it does not add session-level rate limiting or machine learning. Targeted protection adds those: browser interrogation, TLS fingerprinting, behavioral heuristics, and machine learning on your site's traffic. It can challenge bots that do not identify themselves. AWS recommends the client integration SDKs for the targeted level, and says targeted protection is the better default for credential stuffing, advanced scraping, and automated purchasing.

That is still a request verdict. AWS is explicit that account creation fraud is a different control. Account Creation Fraud Prevention (AWSManagedRulesACFPRuleSet) inspects the signup endpoint. It checks email and password pairs against a stolen-credential database, evaluates email domains, monitors phone numbers and address fields, and aggregates by IP address and client session, and by submitted fields such as physical address and phone number. On CloudFront it can also inspect the application's responses and temporarily block sessions or IPs with too many failed attempts. AWS's own comparison table lists it beside Bot Control and account takeover prevention, not inside Bot Control.

Use it if you are already on AWS WAF and the signup form is under bulk creation attacks. It does not follow the account into the product, score a week of behavior, or show you a device shared with four older trials. Those remain an account-layer question. Dregs sits behind Bot Control the same way it sits behind Cloudflare: the WAF keeps the request, Dregs scores the identity, and your app decides.

How Dregs Gets the Visitor IP

You do not forward the CDN's client IP headers to Dregs. The browser tracker calls Dregs itself.

Add the script to every page, with your public key. The snippet is the same one in the tracking manual. The script loads from https://dregs.com/dregs.js, and events go to https://dregs.com/api/events from the visitor's browser. Your Cloudflare zone, your CloudFront distribution, and your WAF are not on that path. Leave the script and the events call on dregs.com. If you proxy either one through your own CDN, Dregs sees the CDN.

<script>
  window.dregs = window.dregs || function() {
    (window.dregs.q = window.dregs.q || []).push(arguments);
  };
  dregs('init', { key: 'pk_your_public_key_here' });
</script>
<script src="https://dregs.com/dregs.js" async></script>

dregs.identify(user.id, { email: user.email, name: user.name });

CF-Connecting-IP is the visitor address Cloudflare sends to your origin. True-Client-IP is the same value under another name, on Enterprise, if you enable that header. X-Forwarded-For may already list earlier hops. Cloudflare's header reference is the source for those three. They are how your application logs the visitor. You do not need to pass them to Dregs.

Server events are the other half, and they are a different connection. A server SDK call comes from your backend, carries no device signature, and is tied to the user only by the identity id. Use the same id you passed to dregs.identify(). The visitor IP on the account comes from the tracker events, not from this call. The eventId makes the signup idempotent, so a retry cannot record it twice. Put the name and email on identityData. That is what Authenticity scores.

// app/api/signup/route.ts
import { Dregs } from '@dregs/sdk';

const dregs = new Dregs(); // reads DREGS_SECRET_KEY

await dregs.track('user.signup', {
  identity: user.id,
  eventId: `signup-${user.id}`,
  data: { plan: 'trial' },
  identityData: { email, name },
});

If you already have Cloudflare's bot score in a Worker, you can copy it into data so a reviewer sees it next to Dregs's observations. On Enterprise Bot Management the Workers field is request.cf.botManagement.score, and request.cf.botManagement.verifiedBot is the verified-bot flag. Dregs stores that payload with the event and shows it in the dashboard. It is context for the people reviewing the account, not an input to the four scores. The same idea works for an AWS WAF label you already have in the application: put it in data. Do not invent a header and expect Dregs to look for it.

What Each Layer Catches

Run through the usual suspects and the split stays clean:

• Volumetric scrapers and known bad sources belong on the edge: bot score or Bot Fight Mode, IP Access Rules, WAF rate limits, AWS WAF Bot Control.
• Verified crawlers and agents you want stay allowed at the edge, and can be marked disregarded in Dregs so they stop affecting other accounts.
• Headless signup scripts that fail JavaScript detections or a targeted Bot Control challenge never become accounts. The ones that slip through still score low on Humanity.
• Repeat free trials, multi accounting, and ban evasion pass the edge, because a person is driving. Uniqueness is the score that connects the accounts.
• Fabricated signups pass a challenge, because the browser is real. Authenticity scores the name and email. AWS Account Creation Fraud Prevention can also inspect the signup request itself. It does not replace the account score.
• Referral and promo abuse happens after the request was allowed, often over days. Behavior scores it as it accumulates.

The edge makes the bouncer's job cheap, which is what it was built for. The blot who clears every check, signs the guest book with a borrowed name, and comes back next Tuesday for another trial is a matter for the account. That is the part Dregs keeps.

Frequently Asked Questions

Further Reading