DEV Community: FindIP

App Attest and Play Integrity won't catch a real phone behind a proxy

FindIP — Sat, 31 Oct 2026 14:08:31 +0000

App Attest and Play Integrity answer one question: is this my genuine app on a genuine device? That's worth knowing, and you should use them. But a real, unmodified app on a real phone passes, whether that phone is on a home connection or behind a proxy in a rack of phones.

So if you're fighting fake signups, bonus farming or account takeover, you need a second question: what network is this request coming from?

Why not check on the device?

You can look for a VPN from inside the app. On Android, NetworkCapabilities.hasTransport(TRANSPORT_VPN) tells you about a VPN on the device. It's fine for showing a message, but it won't help against fraud, for two reasons:

The app is reporting on itself. A modified client can answer whatever it likes.
It can't see a proxy further upstream.

The check belongs on a server, which sees the IP the request actually came from.

What to look at

Network type. Hosting and datacenter networks are rarely a phone on a carrier or home connection.
Known exits. VPN exit nodes, open proxies and Tor exits.
Changes in a session. The IP, network or country switching mid-session.

None of this is proof. iCloud Private Relay, corporate VPNs and carrier NAT are all normal for honest users. So treat the result as risk: let most people through, and ask for an extra step when it's high.

How the pieces fit

	Network scoring	App Attest	Play Integrity
Answers	Is the network behind this action risky?	Is this my genuine app on a genuine Apple device?	Is this my genuine app, from Google Play, on a certified device?
Misses	Whether the app is genuine	The network	The network
Decided by	Your backend	Your backend	Your backend

Run them side by side. The rule for all three is the same: your backend decides, never the app.

With FindIP Shield

Disclosure: we build this. FindIP Shield does the network part, and it's free during the preview. The SDKs are new, so no production apps use them yet.

iOS. Add the Swift package (iOS 15+, no dependencies):

.package(url: "https://github.com/findip-net/findip-shield-swift", from: "1.0.3")

Then, on the login button:

let verdict = try await FindIPShield.track(ShieldEvents.loginAttempt, screen: "login")
// Send verdict.sessionId with the login request; your backend verifies it.

Android. Add the library (Android 8+, INTERNET permission only):

implementation("net.findip:shield-android:1.0.3")

Then, inside a coroutine:

val verdict = FindIPShield.track(ShieldEvents.LOGIN_ATTEMPT, screen = "login")
// Send verdict.sessionId with the login request; your backend verifies it.

Your backend then asks Shield about that session with the secret key and decides. The key in the app is public and proves nothing. See server verification.

Two details matter:

No answer means unknown, not safe. A timeout returns an unknown status, never allow. Decide per action what to do: a login can usually continue, while a signup might ask for an extra check.
Nothing the user typed is sent. No form values, advertising IDs, contacts, location or device fingerprint. The full list is in the docs.

What this won't catch

Network scoring doesn't recognize the same phone behind a new account, and residential proxies are hard for anyone, because they route through real home connections. Pair it with integrity checks and your own account-level limits.

Bots, VPNs and fake checkouts on Shopify: what you can see and what you can do

FindIP — Thu, 22 Oct 2026 15:43:08 +0000

If your Shopify analytics show a spike of sessions from a country you don't ship to, add-to-carts that never convert, or a burst of failed payments at 2 a.m., you're not imagining it. A share of every store's traffic comes from scrapers, price bots, card testers and people hiding behind proxies.

Shopify handles a lot of this for you. Some of it, it doesn't. Here's what you can see, and what you can actually do about it, mostly with tools you already have.

1. What Shopify already does

Before installing anything, know what's on by default:

Platform-level bot protection. Shopify sits behind Cloudflare and filters a lot of abusive traffic before it reaches your store.
hCaptcha on forms. It's on by default for contact, comment, login and account-creation forms. Check it's still on under Online Store > Preferences > Spam protection.
Checkout protection. Shopify runs its own checks on checkout. Extra bot protection during high-traffic sales is a Shopify Plus feature.
Fraud analysis on orders. Eligible orders get a low, medium or high risk recommendation with indicators, and stores on Shopify Payments also get proxy detection. Shopify's own advice is to go by the recommendation, not by any single indicator such as the IP address.

That covers a lot of card fraud. What it doesn't give you is a clear picture of your traffic: how much of it is people, and how much is automated or anonymized.

2. Why the traffic picture matters

Bot and proxy traffic on a store costs you in quieter ways than fraud:

Wrong numbers. Conversion rate, bounce rate and "sessions by country" all include traffic that was never going to buy.
Wasted ad spend. Paid clicks from datacenter networks are rarely shoppers.
Card testing. Waves of small payment attempts, often from rotating proxies, show up as failed payments before they show up as chargebacks.
Scraping. Competitors and resellers pulling your catalog and prices.

The tell is usually the network the traffic comes from. Shoppers browse from home broadband and mobile carriers. Bots and scrapers run on cloud servers (AWS, DigitalOcean, OVH, Hetzner) and route through proxies.

3. What to look at

Whatever tool you use, these are the questions that matter:

What share of page views come from hosting or datacenter networks?
What share of checkouts started come from VPNs, proxies or Tor, and is that share higher than for page views?
Do payment attempts from risky networks cluster in bursts? That's what card testing looks like.
Do spikes in "sessions from country X" line up with a single hosting provider?

You'll usually find a few clear patterns (a scraper on one cloud provider, a burst of proxy checkouts on one night) rather than a general problem. Shoppers on VPNs are mostly real people, so a VPN on its own tells you little.

4. What you can do about it

On Shopify, the store front is yours but checkout is Shopify's, so the levers are:

Problem	What works on Shopify
Spam on contact and account forms	Keep hCaptcha on in spam protection settings
Risky orders	Read the order's fraud analysis, and use Shopify Flow to tag, hold or flag high-risk orders for review
Card-testing waves	Watch failed payments by network and time; Shopify's own checks and your payment provider's rules do the blocking
Scrapers and junk traffic in analytics	Identify the networks, then exclude or segment them in your analytics and ad reports
Blocking whole countries or VPN users on the storefront	Blocker apps can do it with a storefront script; test carefully, since real customers use VPNs and checkout itself stays Shopify's

The general rule holds here too: look before you block. A storefront that blocks every VPN user turns away real customers and still can't touch what happens inside Shopify's checkout.

Where FindIP Shield fits

Disclosure: we make FindIP Shield, which does the "what to look at" part for free.

It uses Shopify's Web Pixels API and reports page views, checkouts started and payment info submitted, each scored for VPN, proxy, Tor, hosting or datacenter network and known malicious IPs, with the reasons, in a dashboard.
It runs only when the shopper has given analytics consent, under Shopify's Customer Privacy controls.
It's deliberately minimal: no names, emails, addresses, customer or order IDs, cart contents, search queries or payment details are sent, and page URLs are stripped of query strings.
It reports; it doesn't block shoppers. Because it never sees order IDs, use Shopify's fraud analysis for individual orders and Shield for the traffic picture around them.
Free up to 10,000 events per site per day.

It's on the Shopify App Store as FindIP Shield, and there's an example dashboard with sample data and a Shopify overview if you want to see what it shows first.

The short version

Use what Shopify already gives you: hCaptcha on forms, fraud analysis on orders.
Find out which networks your traffic comes from: residential, hosting, VPN, Tor.
Look for patterns (one cloud provider, one burst of failed payments) before blocking anything.
Act with Shopify Flow on risky orders and segment junk traffic out of your numbers.
Don't block VPN shoppers outright. Most of them are customers.

How to detect VPN and proxy signups on WordPress (and what to do about them)

FindIP — Thu, 22 Oct 2026 15:29:52 +0000

If you run a WordPress site with open registration, a contact form or a WooCommerce checkout, you've seen it: a wave of new accounts with throwaway emails, contact-form spam at 3 a.m., orders that look fine until the chargeback arrives. A lot of that traffic doesn't come from home internet connections. It comes through VPNs, open proxies, Tor and rented cloud servers.

Detecting that is easy. Deciding what to do with it is where most setups go wrong: millions of legitimate people use a VPN every day, and a site that blocks all of them loses real customers.

Here's how to approach it on WordPress, in the order that keeps false positives low.

1. Know which network your visitors come from

Every request arrives from an IP address, and that address belongs to a network. The useful question isn't "which IP?" but "what kind of network?":

Residential or mobile ISP: home broadband, phone carriers. This is almost everyone.
Hosting or datacenter: AWS, DigitalOcean, OVH, Hetzner and friends. Real people rarely browse from these; scripts and cheap proxies do.
Commercial VPN, open proxy, Tor: anonymized traffic. Common for privacy-minded users, also common for abuse.
Known malicious IPs: addresses already seen scanning, spamming or attacking.

WordPress doesn't tell you any of this. You need an IP intelligence lookup: either a plugin that calls one, or a layer in front of the site (Cloudflare) that classifies traffic for you.

2. Look before you block

The most common mistake is installing a blocker, switching on "block all VPNs", and walking away. Two weeks later a customer emails to say they couldn't check out from their company laptop.

Run in monitor mode first, for a week if you can:

What share of registrations come from hosting networks or VPNs?
What share of orders, and do those orders get refunded or charged back more?
Are your contact-form spam submissions concentrated on a few networks?

You'll usually find that the abuse sits in a few clear patterns (datacenter IPs on the registration form, say), while VPN users on checkout are mostly fine. That tells you exactly where to add friction and where to leave things alone.

3. Watch out for page caching

If you use a full-page cache (WP Rocket, LiteSpeed Cache, W3 Total Cache, or your host's built-in cache), a PHP check that runs when WordPress renders the page doesn't run on a cached page. The cache serves the stored HTML without WordPress ever looking at the visitor's IP. Server-side blocker plugins usually document this and ask you to exclude protected pages from the cache.

Two ways around it:

Check at the edge: a Cloudflare WAF rule or Worker sees every request before the cache.
Check in the browser and on submit: a small script on the page reports the visit and the form submit, so cached pages are covered too. The decision happens when the form is actually submitted.

4. Protect the forms, not the whole site

Blocking every page for every VPN user is a blunt tool. The forms are where abuse costs you money, so put the friction there:

Form	Typical abuse	A reasonable response for risky submits
Registration (`wp-login.php?action=register`, membership plugins)	Bot signups, fake accounts	A Turnstile check or email verification
Login (`wp-login.php`, WooCommerce My Account)	Credential stuffing	A short wait plus a challenge after failures
Contact and lead forms	Spam leads	A challenge for hosting networks only
WooCommerce checkout	Card testing, fraud	A challenge, or hold the order for review

"Risky" should mean several signals together (a datacenter IP plus a brand-new account plus a burst of attempts), not a VPN on its own.

5. Your options on WordPress

There are three common routes, and they combine well:

Cloudflare WAF rules. If your site is behind Cloudflare, custom rules can block or challenge by ASN, country or Cloudflare's own threat signals, before the cache. Powerful, but you write and maintain the rules yourself, and you don't get a per-form view of what happened.
A blocker plugin backed by an IP API. Plugins such as Proxy & VPN Blocker (proxycheck.io) or VPN Guard (vpnapi.io) check the visitor IP against an API and block or redirect on pages you choose. Simple and effective for hard blocking; mind the caching caveat above and the API's daily quota.
A monitoring-first plugin with form protection. Score every visit and form submit, see the reasons in a dashboard, and add friction only on the forms and signals that turn out to matter.

Where FindIP Shield fits

Disclosure: we make FindIP Shield, a free plugin for the third route.

Every visit, signup, login and WooCommerce checkout gets a risk score with the reasons: VPN, proxy, Tor, relay, hosting or datacenter network, or a known malicious IP.
It runs on regular pages and on wp-login.php, in the browser, so full-page caching doesn't skip it.
With WooCommerce active it adds cart, checkout, payment-failure and order-completion context, so you can see which orders came through anonymizing networks.
It doesn't block anything by default. When you're ready, you switch on form protection from the dashboard and choose what a risky visitor sees: a message, a short wait, or a Cloudflare Turnstile check.
It never reads form values, passwords, emails or payment details, and starts in strict privacy mode.
Setup is install, click Connect, pick your site. Free up to 10,000 events per site per day.

It's on WordPress.org as FindIP Shield: VPN, Proxy & Bot Traffic Detection, and there's an example dashboard with sample data if you want to see what it shows before installing.

The short version

Find out which networks your visitors come from: residential, hosting, VPN, Tor.
Monitor for a week before blocking anything.
Remember that page caching skips server-side checks; check at the edge or in the browser.
Add friction on the forms where abuse costs money, when several signals stack up.
Never block VPN users outright. Challenge them when the rest of the picture looks wrong.

How to stop free-tier abuse on an AI app (without killing signups)

FindIP — Thu, 22 Oct 2026 14:22:24 +0000

On most SaaS products a fake free account costs you a row in a database. On an AI app it costs you tokens. Every new account that burns its free credits is a bill, and the people who farm free tiers know it: new email, new browser profile, sometimes a VPN, same workload as yesterday.

The usual fixes each have a hole. Email verification stops nobody with a disposable inbox. A card on the free tier stops the abuse and most of your signups with it. IP rate limits lock out a whole office behind one NAT.

What works is layers, each cheap on its own, ordered so the first ones protect your bill even before you catch anyone. This is the setup, in the order we'd build it.

1. Cap the blast radius first

Before you try to detect anything, make sure the worst case is a number you chose.

A global daily budget for all free usage. When it's spent, free requests queue or wait until tomorrow. One bad night can't become a surprise invoice.
A per-account daily cap that's lower than you think you need.
Check both on the server, before the model call, not after.

// Before calling the model for a free-tier user
async function canSpendFree(userId: string, estTokens: number) {
  const today = new Date().toISOString().slice(0, 10);
  const [global, user] = await Promise.all([
    redis.incrby(`free:global:${today}`, estTokens),
    redis.incrby(`free:user:${userId}:${today}`, estTokens),
  ]);
  await redis.expire(`free:global:${today}`, 172800);
  await redis.expire(`free:user:${userId}:${today}`, 172800);
  return global <= GLOBAL_FREE_DAILY && user <= USER_FREE_DAILY;
}

This doesn't stop farming. It makes farming boring and bounded, which is most of the battle.

2. Make each account worth less

Farming is economics. Lower the payout per account and most farmers stop.

Drip credits instead of one lump. "50 a day for a week" is far less worth farming than "350 now". An honest user barely notices.
Start new accounts on a cheaper model. The good model unlocks after email verification and a bit of normal use. The farmer's cost per account goes up; yours goes down.
Unlock more with trust: account age, normal usage, a verified email, or a card, but ask for the card only when an account looks risky (step 5).

3. Clean up the email layer

Not because it stops determined people, but because it's an afternoon of work and removes the laziest farming.

const DISPOSABLE = new Set(disposableDomains); // e.g. the open-source "disposable-email-domains" list

export function normalizeEmail(raw: string) {
  const [local, domain] = raw.trim().toLowerCase().split('@');
  const d = domain === 'googlemail.com' ? 'gmail.com' : domain;
  let l = local.split('+')[0];                 // drop +tags
  if (d === 'gmail.com') l = l.replace(/\./g, ''); // Gmail ignores dots
  return { email: `${l}@${d}`, disposable: DISPOSABLE.has(d) };
}

Store the normalized email with a unique index, and keep a hash of it when an account is deleted, so "delete and sign up again" doesn't reset the free tier.

4. Group accounts instead of judging each one

A single signal proves nothing. A VPN is common for privacy-minded users; a shared IP is every office and mobile carrier. What gives farmers away is that their accounts look alike:

Network type, not just IP. An office NAT or a mobile carrier is a residential or mobile ISP. Ten accounts in an hour from VPN exits and cloud servers are not. This distinction is what keeps your false positives down.
Network changes inside one session: the IP, ASN or country switching mid-signup is a strong sign of a rotating proxy.
Timing: a new signup minutes after the previous account ran out of credits.
Workload: the same first prompts, files or project shape as an older account.

Log these for every signup from day one. You can't cluster history you didn't keep.

5. Add friction only where signals stack up

Now use the signals, gently:

Signals	Response
Nothing unusual	Straight in, normal free tier
One weak signal (a VPN, say)	Straight in, maybe the drip starts smaller
Several signals, or a known-bad network	A Turnstile check, email or phone verification before credits
Clearly the same person as a capped account	No free credits until they verify with a card

The honest majority never sees any of this. The farmer sees it on every account.

Where FindIP Shield fits

Disclosure: we make FindIP Shield, a free tool that does the network part of steps 4 and 5. It scores each visit and form submit from 0 to 100 with the reasons (VPN, proxy, Tor, hosting or datacenter network, known malicious IP, IP changes during the session), and can add a short wait, a Turnstile check or a stop message for risky submits only, off until you switch it on. It scores the network, not the device: there's no device fingerprinting, so on its own it won't recognize the same laptop on a fresh profile. It never reads form values.

The browser side is one script tag:

<script
  src="https://cdn.findip.net/shield/v1.js"
  data-site-key="pub_xxxxxxxxx"
  data-auto-track="true"
  data-privacy-mode="balanced">
</script>

Send the Shield session ID with your signup request (FindIP.getSession().sessionId), then let your server make the decision, because anything decided in the browser can be bypassed:

async function shieldVerdict(sessionId: string) {
  const res = await fetch('https://shield.findip.net/v1/shield/sessions/verify', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.SHIELD_SECRET_KEY}`, // sec_..., server only
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ session_id: sessionId, event: 'signup_attempt' }),
  });
  const v = await res.json();

  // Unknown is not safe: no session, or no IP intelligence for it.
  if (!v.verified || v.risk_status === 'unknown') return 'monitor';
  if (v.recommendation === 'block') return 'require_card';
  if (v.recommendation === 'challenge') return v.challenge_passed ? 'allow' : 'require_verification';
  return 'allow';
}

Combine that verdict with your own signals from steps 3 and 4, and feed it into the table in step 5. Shield is free up to 10,000 events per site per day; there's also a WordPress plugin, a Shopify app, a GTM template and a no-code Cloudflare integration if your signup page isn't hand-written.

The short version

Cap global and per-account free spend on the server.
Drip credits and start new accounts on a cheaper model.
Normalize emails, block disposable domains, remember deleted accounts.
Cluster accounts by network type, timing and workload.
Add friction only where signals stack up, and never block VPN users outright.

You won't stop every determined person. You don't need to: you need farming to cost them more than it saves, while honest users still get in with one click.

We made visitor risk scoring free. Here's how to add it to signup and checkout

FindIP — Mon, 12 Oct 2026 14:22:14 +0000

Fake signups and trial abuse cost money before anyone pays you: compute, emails, support time. The usual fixes are a CAPTCHA on every visitor, which costs you real signups, or a fraud vendor that bills per lookup.

We are the FindIP team, a small group of developers. For years, developers have used our IP intelligence API to find out where a connection really comes from: its location, and whether it is a VPN, a proxy, Tor or a datacenter. In all that time we watched them build the same thing on top of it, again and again: look up the IP on signup, keep some state, decide whether to add friction. So we built it properly, once, and made it free. It is called FindIP Shield.

See your own connection scored in the live demo. No signup needed.

What you get, free:

A 0 to 100 risk score with reasons on every signup, login, lead and checkout attempt: VPN, proxy, Tor, hosting network, known-malicious address.
Rotation detection. A session whose IP, network or country changes midway is flagged.
A response per form that you choose: watch only, slow down, a Turnstile check, or stop. Installing changes nothing until you pick one.
No metering. API calls are unlimited under fair usage, and each site records up to 10,000 events a day. No credit card.
Privacy by design. The SDK is MIT licensed and never reads what a visitor types.

This post shows how to add it in four steps. The pattern works without Shield too, so if you take one thing away, take the rule below.

The rule: a browser-side risk result is for visibility and user experience. If a result is going to deny access, stop a payment or add real friction, verify the session on your server first.

The case we are designing for

A product offers a free trial and a discounted first payment. Someone creates several accounts with different emails. The per-IP limit catches the first burst. Later attempts arrive through different proxies and hosting providers, one or two per address, and look like ordinary signups.

No single detail proves anything. The useful part is the combination: repeated signup events, changing infrastructure, and elevated network risk around the same valuable action. The application needs three answers:

What action just happened?
What explains the risk result?
What is the least disruptive response that still protects the product?

Step 1: report the action, not the person

Install the SDK once near the browser entry point. The script-tag form is the same idea for sites without a bundler.

npm install @findip/shield

import { init, track, getSession } from '@findip/shield';

init({
  siteKey: 'pub_xxxxxxxxx',
  privacyMode: 'balanced',
  autoTrack: true,
  autoDetectForms: true,
});

The SDK recognises common signup, login, lead and checkout forms from their attributes, and reports the submit itself as signup_attempt, login_attempt and so on. Do not send the same attempt again from your own code, or it is counted twice. Use track() for what the form cannot know: the outcome, or an attempt that fires no form submit event, such as a request sent from a click handler.

Keep the context small and business-shaped. A plan name or an email domain explains an event; a raw email, a password or a card number has no place in the payload.

// Form detection already sent signup_attempt. Report the outcome.
const result = await track('signup_success', {
  email_domain: 'example.com',
  plan: 'free',
});

if (!result?.risk) {
  // No result came back. This is "we do not know", not "safe".
}

Checkout follows the same rule: transaction_amount and currency are context; payment details are not.

Step 2: decide what each result means before launch

The result carries a score when intelligence is available, a recommendation and readable reasons (proxy, Tor, hosting network, a rotating IP inside the session, a malicious-IP category). Decide the response table now, not after the first suspicious checkout:

Recommendation	Reasonable response
`allow`	Continue. Rate limits and account checks still apply.
`monitor`	Continue, keep the event for correlation.
`challenge`	Something proportionate: email confirmation, MFA, a Turnstile check.
`block`	Only under a documented server-side policy, with a recovery path.
No result, or `unknown` status from the server check	Intelligence was unavailable. Not a score of zero.

The mistake that makes risk scoring hateful is turning one signal into a hard rule. A VPN flag is not proof of fraud. Corporate networks, privacy-conscious customers, mobile carriers and travellers all show up with signals that look odd in isolation.

Step 3: do not make the browser a trust boundary

Anyone who can open developer tools can rewrite browser code or fabricate a result. So the browser never decides. It passes the session ID along with the business request, and the server verifies it with a secret key that only the server holds.

// Browser: attach the session to the signup request.
const { sessionId } = getSession();
await fetch('/api/signup', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email, password, findip_session_id: sessionId }),
});

// Server: verify before enforcing anything.
const response = await fetch('https://shield.findip.net/v1/shield/sessions/verify', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.FINDIP_SHIELD_SECRET_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ session_id: req.body.findip_session_id, event: 'signup_attempt' }),
});
const verified = await response.json();

if (!verified.verified || verified.risk_status === 'unknown') {
  return continueWithoutRiskBasedEnforcement();
}
if (verified.recommendation === 'block') {
  return rejectUnderDocumentedPolicy();
}
if (verified.recommendation === 'challenge' && !verified.challenge_passed) {
  return requireAdditionalVerification();
}

The verified response also describes the whole session: distinct IPs and networks seen, whether the IP or ASN rotated, and network flags that were true for any event. That is the record you want in a fraud queue or an order note, and it comes from the server, not from the page.

For plain HTML forms, sessionField: true makes the SDK add the session ID as a hidden field, so the server does not depend on a cookie that a privacy-minded browser may refuse.

Step 4: choose a privacy mode on purpose

Mode	Fits	Behaviour
`strict`	Consent denied, or minimal collection	Session-only identity, no visitor cookie, user agent, language and time zone only. Form metadata, never values
`balanced`	A sensible default	Adds a 30-day first-party visitor ID, screen and device details, and an optional picture of a form with every value blanked
`advanced`	Longer retention	The same fields as `balanced`, marked for extended retention

Every mode excludes what a visitor types: passwords, card numbers, emails, phone numbers and every other field value. No keystrokes, no page HTML, no screenshot of the page and no session recording. The one picture is the blanked form in balanced and advanced, and captureFormSnapshots: false turns it off. On ingestion the event is rebuilt from an allowlist rather than stored as whatever the browser sent.

What we would not do

Switch on automatic blocking on day one. Watch ordinary traffic first, long enough to learn what your employees, your corporate customers and your mobile users look like.
Treat an unavailable lookup as a score of zero. Handle unknown explicitly on both sides.
Reject a payment on a browser-side score. Verify, then decide, and give a legitimate user a way to recover when a challenge fails.
Collect "just the email" for convenience. Hash it in the browser if you need to tie a session to an account; the SDK does that for you.

Before adding friction

Confirm the allowed domain is right and the first event reaches the dashboard.
Run in visibility mode long enough to understand normal traffic.
Use the lowest privacy mode that gives the context you actually need.
Handle unknown explicitly in browser and server code.
Verify any decision that stops a signup, payment or account action.
Give legitimate users a recovery path when a challenge fails.

Try it

See it first: the live demo scores your own connection and shows a sample dashboard. No signup.
Install it: the quickstart covers npm, a script tag, WordPress, Shopify, Google Tag Manager and a no-code Cloudflare Worker.
Read the code: the SDK is on GitHub under the MIT licence.

We would like to hear what would make this more useful to you. Questions about the trust model are welcome in the comments.

Disclosure: we are the FindIP team, and Shield is our product. It is free in its current preview. The full guide is the canonical version at findip.net.