DEV Community: ABDULLAH AFZAL

Build Impossible Travel Detection Into Your Login Flow

ABDULLAH AFZAL — Thu, 04 Jun 2026 05:54:06 +0000

Impossible travel is two logins to one account from places too far apart to travel between in the time that passed. New York at 9:00, Singapore at 9:40. No passenger makes that trip, so one of those sessions is almost certainly not the account owner. You can catch it in your own login flow with an IP lookup, the Haversine formula, and a velocity check, and this walks through the whole build in Node and Python.

It earns its place because login endpoints are under constant credential pressure. In Verizon's 2025 DBIR research on credential stuffing, credential stuffing was a median 19% of all authentication attempts across the SSO logs they analyzed, and stolen credentials were the initial access vector in 22% of breaches. Impossible travel is one of the cheapest ways to catch the attempts that actually succeed.

TL;DR:

Impossible travel flags a login when distance from the previous login divided by the time between them implies a speed no human travel can reach.
The build is small: geolocate the IP to coordinates, measure great-circle distance with the Haversine formula, divide by elapsed time, compare to a threshold around 1000 km/h.
Store each user's last login location and timestamp (Redis works well) so the next login has something to compare against.
The velocity check alone fires on every corporate-VPN user and frequent flyer. Security signals (is_vpn, is_relay, is_residential_proxy, threat_score) are what separate a real anomaly from noise.
Respond in tiers (allow, log, step-up MFA, block) and fail open: a lookup timeout should never lock a user out.

Geolocation is reliable enough at the country and region level to make this work and too rough at the street level to trust there, so the thresholds stay loose. The signal you want is "these two cities are thousands of kilometers and a few minutes apart," not "the user moved across town."

What impossible travel detection actually catches

Two terms get mixed up. A typical travel is a login from an unusual place that is still physically possible, like a user who normally signs in from Berlin appearing in Toronto after a flight. Impossible travel is a login that could not have happened given the time elapsed. The first is worth a note; the second is worth interrupting the session.

As a signal it targets account takeover. When an attacker replays stolen credentials from their own machines or a proxy pool, the source location rarely lines up with where the real user has been. Rate limiting and bot defenses thin out the automated noise at the perimeter; impossible travel catches the login that got through with a correct password. It is a strong signal, not proof. A VPN, a privacy relay, or a frequent traveler can all trip it, which is why the response matters as much as the detection. Treat a hit as "this needs more scrutiny," not "this is an attacker."

The check, before any code

The logic is short. Take the user's last login (latitude, longitude, timestamp) and the current one. Measure the great-circle distance between the two points. Divide by the hours elapsed to get an implied travel speed. If that speed is higher than anything a human can manage, flag it. Then decide what to do, using the IP's security signals to tell a real anomaly apart from a VPN exit.

Get the client IP right

The whole check depends on reading the correct client IP, and behind a load balancer or CDN the socket address is the proxy, not the user. The real address sits in X-Forwarded-For. That header is also trivially spoofable if you accept it from anywhere, so only trust it from infrastructure you control.

In Express, set the trust proxy level to the number of proxies in front of you, then read req.ip:

// One proxy/CDN in front of the app. Set the real hop count for your setup.
// Trusting X-Forwarded-For blindly lets a client spoof their location.
app.set("trust proxy", 1);

// Now req.ip is the client address as reported by your trusted proxy.
const ip = req.ip;

In FastAPI, run Uvicorn with --proxy-headers and a trusted-host list, then read the forwarded client:

# Start with: uvicorn app:app --proxy-headers --forwarded-allow-ips="10.0.0.0/8"
# request.client.host is then the forwarded client IP, not the proxy.
ip = request.client.host

Pitfall: if your app is reachable directly as well as through the proxy, an attacker can hit it directly and set their own X-Forwarded-For. Lock direct access down at the network layer, or the location signal is meaningless.

Geolocate the IP to coordinates

You need latitude and longitude for the IP. Any IP geolocation provider returns this: IPGeolocation, ipinfo, ip-api, MaxMind GeoIP2, and IPLocate all do. The examples here use IPGeolocation because the free tier returns coordinates, city, and country in one call with no card required, which keeps the tutorial to one dependency. Create a free key and put it in an environment variable.

The raw call is one GET request:

curl 'https://api.ipgeolocation.io/v3/ipgeo?apiKey=YOUR_KEY&ip=8.8.8.8'

For 8.8.8.8 that comes back with location.city of "Mountain View", location.country_name of "United States", and coordinates under location. One detail that will bite you if you miss it: the coordinates are returned as strings, so parse them before doing math.

Node, with a timeout and a fallback so a slow lookup never blocks a login:

const IPGEO_API_KEY = process.env.IPGEO_API_KEY;
if (!IPGEO_API_KEY) {
  throw new Error("IPGEO_API_KEY is not set");
}

// withSecurity adds the VPN/proxy signals (paid tier). See the false-positive section.
async function locateIp(ip, { withSecurity = false } = {}) {
  const include = withSecurity ? "&include=security" : "";
  const url = `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${IPGEO_API_KEY}&ip=${encodeURIComponent(ip)}${include}`;

  try {
    const res = await fetch(url, { signal: AbortSignal.timeout(1500) });
    // 423 means a bogon/private IP the API won't locate. Treat as "no location".
    if (!res.ok) return null;

    const data = await res.json();
    const loc = data?.location;
    if (!loc?.latitude || !loc?.longitude) return null;

    // Coordinates arrive as strings. Reject anything that isn't a finite number.
    const lat = Number.parseFloat(loc.latitude);
    const lon = Number.parseFloat(loc.longitude);
    if (!Number.isFinite(lat) || !Number.isFinite(lon)) return null;

    return {
      lat,
      lon,
      city: loc.city ?? null,
      country: loc.country_name ?? null,
      security: data.security ?? null,
    };
  } catch (err) {
    // Timeout or network error: fail open, log for review.
    console.error(`Geo lookup failed for ${ip}: ${err.message}`);
    return null;
  }
}

Python with FastAPI, same shape:

import os
import httpx

IPGEO_API_KEY = os.environ.get("IPGEOLOCATION_API_KEY")
if not IPGEO_API_KEY:
    raise RuntimeError("IPGEOLOCATION_API_KEY is not set")

async def locate_ip(ip: str, with_security: bool = False):
    params = {"apiKey": IPGEO_API_KEY, "ip": ip}
    if with_security:
        params["include"] = "security"

    try:
        async with httpx.AsyncClient(timeout=1.5) as client:
            resp = await client.get("https://api.ipgeolocation.io/v3/ipgeo", params=params)
        if resp.status_code != 200:  # 423 for bogon/private IPs
            return None

        body = resp.json()
        loc = body.get("location") or {}
        lat, lon = loc.get("latitude"), loc.get("longitude")
        if lat is None or lon is None:
            return None

        try:                       # strings in the response; reject bad values
            lat, lon = float(lat), float(lon)
        except (TypeError, ValueError):
            return None

        return {
            "lat": lat,
            "lon": lon,
            "city": loc.get("city"),
            "country": loc.get("country_name"),
            "security": body.get("security"),
        }
    except httpx.HTTPError as err:
        print(f"Geo lookup failed for {ip}: {err}")  # fail open
        return None

A word on accuracy

Country and region accuracy is high. City-level placement is rougher, and it gets worse on mobile carriers and carrier-grade NAT, where one tower or gateway can cover a wide area. So compare distance, not exact coordinates, and keep the threshold well above any plausible margin of error. You are looking for a jump between continents, not a wobble between neighborhoods.

Measure the distance with the Haversine formula

The Haversine formula gives the great-circle distance between two latitude/longitude points, which is the shortest path over the surface of a sphere. Close enough to real distance for this purpose.

function haversineKm(lat1, lon1, lat2, lon2) {
  const R = 6371; // Earth radius in km
  const toRad = (deg) => (deg * Math.PI) / 180;
  const dLat = toRad(lat2 - lat1);
  const dLon = toRad(lon2 - lon1);
  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(toRad(lat1)) * Math.cos(toRad(lat2)) * Math.sin(dLon / 2) ** 2;
  // Clamp to 1 so floating-point error can't push asin out of its domain.
  return 2 * R * Math.asin(Math.min(1, Math.sqrt(a)));
}

from math import radians, sin, cos, asin, sqrt

def haversine_km(lat1, lon1, lat2, lon2):
    r = 6371.0  # Earth radius in km
    d_lat = radians(lat2 - lat1)
    d_lon = radians(lon2 - lon1)
    a = sin(d_lat / 2) ** 2 + cos(radians(lat1)) * cos(radians(lat2)) * sin(d_lon / 2) ** 2
    # Clamp to 1 so floating-point error can't push asin out of its domain.
    return 2 * r * asin(min(1, sqrt(a)))

New York to Singapore is about 15,300 km. Forty minutes apart, that implies a speed near 23,000 km/h, which settles the question.

Turn distance and time into a velocity check

Speed is distance over time. The threshold is the one judgment call. A commercial jet cruises near 900 km/h, so anything materially above that is not a real trip. I use 1000 km/h to leave room for the rough edges of city-level geolocation. Two guards keep it sane: ignore short distances, which are geolocation jitter rather than travel, and handle a near-zero time gap so you do not divide by zero.

const MAX_PLAUSIBLE_KMH = 1000; // above a commercial jet (~900 km/h), with margin
const MIN_DISTANCE_KM = 100;    // below this is local movement or geo jitter

function isImpossibleTravel(prev, current) {
  const km = haversineKm(prev.lat, prev.lon, current.lat, current.lon);
  if (km < MIN_DISTANCE_KM) return false;

  const hours = (current.ts - prev.ts) / 3600;
  if (hours <= 0) return true; // same second or clock skew, but the cities are far apart

  return km / hours > MAX_PLAUSIBLE_KMH;
}

MAX_PLAUSIBLE_KMH = 1000
MIN_DISTANCE_KM = 100

def is_impossible_travel(prev, current):
    km = haversine_km(prev["lat"], prev["lon"], current["lat"], current["lon"])
    if km < MIN_DISTANCE_KM:
        return False

    hours = (current["ts"] - prev["ts"]) / 3600
    if hours <= 0:
        return True

    return (km / hours) > MAX_PLAUSIBLE_KMH

The first login for a user has nothing to compare against, so it always passes. That is fine; the check starts protecting from the second login onward.

Store login history

You need the previous login's location and time. Redis fits because the lookup happens on every login and you want it fast. Store one record per user keyed by user ID, with a TTL so dormant accounts age out.

import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL);
const HISTORY_TTL = 60 * 60 * 24 * 30; // 30 days

async function getLastLogin(userId) {
  try {
    const raw = await redis.get(`login:last:${userId}`);
    return raw ? JSON.parse(raw) : null;
  } catch (err) {
    console.error(`Redis read failed: ${err.message}`);
    return null; // fail open: no history means the check is skipped, not blocked
  }
}

async function saveLastLogin(userId, record) {
  try {
    await redis.set(`login:last:${userId}`, JSON.stringify(record), "EX", HISTORY_TTL);
  } catch (err) {
    console.error(`Redis write failed: ${err.message}`);
  }
}

import json
import redis.asyncio as redis

redis_client = redis.from_url(os.environ.get("REDIS_URL", "redis://localhost:6379"))
HISTORY_TTL = 60 * 60 * 24 * 30  # 30 days

async def get_last_login(user_id: str):
    try:
        raw = await redis_client.get(f"login:last:{user_id}")
        return json.loads(raw) if raw else None
    except redis.RedisError as err:
        print(f"Redis read failed: {err}")  # fail open
        return None

async def save_last_login(user_id: str, record: dict):
    try:
        await redis_client.set(f"login:last:{user_id}", json.dumps(record), ex=HISTORY_TTL)
    except redis.RedisError as err:
        print(f"Redis write failed: {err}")

Tip: no Redis in your stack? A row per user in your existing database works the same way. You only read and write one small record per login, so the storage choice barely matters until you are doing this at high volume.

Wire it into the login flow

The check runs after the password is verified and before you hand back a session. In Express, that is middleware mounted after authentication, where req.user exists.

async function checkImpossibleTravel(req, res, next) {
  const userId = req.user?.id;
  if (!userId) return next(); // nothing authenticated to check

  const current = await locateIp(req.ip);
  if (!current) return next(); // private IP or lookup failed: fail open

  const now = Math.floor(Date.now() / 1000);
  const record = { lat: current.lat, lon: current.lon, city: current.city, ts: now };

  const prev = await getLastLogin(userId);

  if (prev && isImpossibleTravel(prev, record)) {
    // Suspicious: hold the record. Do NOT move the baseline yet, or a blocked
    // attacker overwrites the user's trusted location. Persist it after step-up.
    req.loginRisk = { impossibleTravel: true, from: prev.city, to: current.city, currentLogin: record };
    return next();
  }

  // Clean login: this becomes the new trusted baseline.
  await saveLastLogin(userId, record);
  next();
}

In FastAPI, call it inside the login route once credentials check out, since middleware runs before you know who the user is:

import time

async def evaluate_login(user_id: str, ip: str):
    current = await locate_ip(ip)
    if not current:
        return None  # fail open

    record = {"lat": current["lat"], "lon": current["lon"],
              "city": current["city"], "ts": int(time.time())}

    prev = await get_last_login(user_id)

    if prev and is_impossible_travel(prev, record):
        # Suspicious: hold the record, don't move the baseline yet (see note below).
        return {"impossible_travel": True, "from": prev["city"],
                "to": current["city"], "current_login": record}

    # Clean login: this becomes the new trusted baseline.
    await save_last_login(user_id, record)
    return None

One rule makes or breaks this: only promote a login to the trusted baseline once it is actually trusted. The code above saves it right away for a clean login but holds it when the jump looks impossible. Persist the held record only after the user clears step-up authentication. Skip that and a blocked attacker overwrites the baseline, and the real user's next login then looks anomalous against the attacker's location.

// Call after the user passes step-up (correct MFA code, passkey, and so on).
async function onStepUpPassed(req) {
  const userId = req.user?.id;
  const record = req.loginRisk?.currentLogin; // the login we held back
  if (userId && record) await saveLastLogin(userId, record);
}

async def on_step_up_passed(user_id: str, risk: dict):
    record = (risk or {}).get("current_login")  # the login we held back
    if record:
        await save_last_login(user_id, record)

At this point a real account takeover from a fresh location gets flagged. So does every employee on a corporate VPN.

The false positives that will bite you

Run the velocity check on real traffic and the flags pile up from people who are not attackers:

Someone on a corporate VPN whose egress sits in another country.
An iPhone user behind iCloud Private Relay, which presents a relay IP, not their own.
A phone hopping between a mobile carrier and home WiFi, where the carrier IP geolocates hundreds of kilometers off.
A genuine frequent flyer who lands and logs in before your record updates.

Block on the raw velocity signal and you will lock these people out daily. The fix is to ask one more question about the IP: is it an anonymizing service, and how risky is it.

Suppress false positives with security signals

IPGeolocation's IP Security API returns risk signals for an IP: a threat_score from 0 to 100, plus flags for VPN, proxy, residential proxy, Tor, relay, and more, with provider names and confidence scores. It is a dedicated /v3/security endpoint, but you can fold it into the same geolocation call with include=security, which gets you coordinates and risk in one request. That is the withSecurity flag the lookup function already takes.

A full response looks like this (for the documented example IP 2.56.188.34):

{
  "ip": "2.56.188.34",
  "security": {
    "threat_score": 80,
    "is_tor": false,
    "is_proxy": true,
    "proxy_provider_names": ["Zyte Proxy"],
    "proxy_confidence_score": 80,
    "proxy_last_seen": "2025-12-12",
    "is_residential_proxy": true,
    "is_vpn": true,
    "vpn_provider_names": ["Nord VPN"],
    "vpn_confidence_score": 80,
    "vpn_last_seen": "2026-01-19",
    "is_relay": false,
    "relay_provider_name": "",
    "is_anonymous": true,
    "is_known_attacker": true,
    "is_bot": false,
    "is_spam": false,
    "is_cloud_provider": true,
    "cloud_provider_name": "Packethub S.A."
  }
}

The distinction that matters here is residential proxy versus commercial VPN. A commercial VPN or a privacy relay is overwhelmingly a real person protecting their traffic, so an impossible-travel hit from one is usually noise, especially on a device you already recognize. A residential proxy is different: those are sold to route traffic through other people's home connections specifically to look like organic users and dodge IP reputation, and they show up in credential-stuffing campaigns far more than in normal browsing. So the response leans on two things: how anonymized the IP is, and whether the device is one you have seen before.

function decideResponse(risk, security, context = {}) {
  if (!risk?.impossibleTravel) return "ALLOW";

  const s = security ?? {};
  const threatScore = Number(s.threat_score ?? 0);
  const knownDevice = Boolean(context.knownDevice);

  // Strong abuse signals win regardless of the travel jump.
  if (s.is_known_attacker || threatScore >= 80 || s.is_residential_proxy) {
    return "BLOCK";
  }
  // A commercial VPN or relay explains the jump, but attackers use them too.
  // Trust it only on a device we recognize; otherwise step up.
  if (s.is_vpn || s.is_relay || s.is_proxy) {
    return knownDevice ? "LOG" : "CHALLENGE";
  }
  // Clean IP, real geographic impossibility: step up to MFA before trusting the session.
  return "CHALLENGE";
}

def decide_response(risk, security, context=None):
    if not risk or not risk.get("impossible_travel"):
        return "ALLOW"

    context = context or {}
    s = security or {}
    threat_score = int(s.get("threat_score") or 0)
    known_device = bool(context.get("known_device"))

    if s.get("is_known_attacker") or threat_score >= 80 or s.get("is_residential_proxy"):
        return "BLOCK"
    if s.get("is_vpn") or s.get("is_relay") or s.get("is_proxy"):
        return "LOG" if known_device else "CHALLENGE"
    return "CHALLENGE"

The response now keys on both signals. A known device on a VPN or relay during an impossible-travel hit gets logged; the same hit from an unknown device gets a step-up challenge instead of a free pass. A residential proxy, a known attacker, or a threat score at the ceiling blocks regardless. A clean IP making a real geographic jump always challenges. The knownDevice flag is the tunable part: feed it from a device cookie or fingerprint (the same signal mentioned at the end of this article), and move the thresholds to match your own risk tolerance.

The lookups split along the free and paid line. For the free velocity check, call locateIp(req.ip). To get the VPN, relay, proxy, residential-proxy, and threat-score signals this section relies on, call locateIp(req.ip, { withSecurity: true }) (and locate_ip(ip, with_security=True) in Python), then pass the security object and the device context into the decision: decideResponse(risk, current.security, { knownDevice }). Security data is a paid-tier feature, so the velocity check stands on its own and you add this layer when you are ready to cut the false positives.

Respond, don't just block

Detection is the easy half. The response is where you protect users without alienating them. Four tiers cover it:

ALLOW: no anomaly. The default for almost every login.
LOG: a recognized device on a VPN, relay, or proxy. The jump is explained and the device is known, so record it and move on.
CHALLENGE: a real geographic impossibility on a clean IP, or an unknown device behind a VPN or proxy. Require a second factor before issuing the session.
BLOCK: anomaly plus strong abuse signals (residential proxy, known attacker, or a threat score at the ceiling). Refuse and alert.

And fail open. If the geolocation or security lookup times out, or Redis is down, allow the login and log the gap. A missed anomaly is a recoverable risk. A customer locked out at 2am because your IP provider had a slow minute is a support ticket and a churned account. Availability wins on the login path; run the check, but never let it become a hard dependency.

A few notes before you ship

Store and compare timestamps in UTC, or a user crossing a timezone will produce phantom anomalies. IPv6 works the same way; the geolocation call handles both address families, so no special casing. Pair the location signal with a device signal if you can: a recognized device cookie or fingerprint lets you soften the response for a known laptop on a new network, which is most of your real false positives.

And know when not to build this. If you are already on an identity platform, the feature probably ships in the box: WorkOS Radar, Microsoft Entra ID Protection, Okta, and Datadog all detect impossible travel. Configure theirs instead of rebuilding it. Build your own when you are not on one of those, when you want the signal feeding your own risk engine, or when you want full control over the thresholds and the response.

Start with the velocity check on the free geolocation tier and watch your logs for a week before you switch on any blocking. Add the security signals once you see how many of your "impossible" logins are just people on a VPN. Keep the threshold loose the whole time, and let the step-up prompt, not a hard block, carry the cases you are unsure about.

ASN Lookup for Security Engineers: From Concept to Code

ABDULLAH AFZAL — Tue, 19 May 2026 18:21:25 +0000

An ASN lookup is the fastest way to find out who actually operates the network behind an IP address. Every publicly routable IP on the internet belongs to an autonomous system, and that autonomous system number (ASN) identifies the network operator, what infrastructure they run, and who they peer with. For security engineers, this is a first-order pivot point: when an IP shows up in your logs tied to credential stuffing or port scanning, the ASN tells you whether you're looking at a residential ISP, a cloud hosting provider, or a known bulletproof hosting operation.

This tutorial covers what ASNs are, how they fit into internet routing, and then gets to the practical part: querying ASN data programmatically with curl, Python, and JavaScript so you can fold it into your investigation workflow or SIEM pipeline.

TL;DR

An ASN (Autonomous System Number) uniquely identifies a network that participates in internet routing via BGP.
As of 2025, roughly 120,000 ASNs had been allocated globally, while the number actively visible in BGP routing tables varied by dataset and vantage point.
ASNs classify into three types: stub (one upstream), multi-homed (multiple upstreams), and transit (carries traffic for others).
Security engineers use ASN data for threat attribution, network-level blocking, infrastructure mapping, and log enrichment.
Programmatic ASN lookups return the network operator, organization type (ISP, hosting, business, education), route prefixes, and peering relationships.
This tutorial includes working code for ASN lookups in curl, Python, and JavaScript using ipgeolocation.io's ASN API.

In short: IP addresses identify devices, ASNs identify the networks those devices belong to. Knowing the network behind an IP is often more actionable than knowing the IP itself.

What Is an Autonomous System (and Why Does It Have a Number)

An autonomous system (AS) is a collection of IP address ranges, called prefixes, that operate under a single routing policy managed by one organization. An ISP like Comcast, a cloud provider like AWS, and a CDN like Cloudflare each operate their own autonomous systems. Internally, an AS can run whatever routing protocols it wants (OSPF, IS-IS, EIGRP). Externally, it presents one consistent set of rules about which IP prefixes it controls and how traffic reaches them.

Each AS gets a unique number: its ASN. These are assigned by IANA through five Regional Internet Registries (RIRs): ARIN (North America), RIPE NCC (Europe, Middle East, Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America), and AFRINIC (Africa). The original 16-bit format allowed 65,536 ASNs. The 32-bit format, standardized in RFC 6793, extends that to over 4.2 billion. As of 2025, roughly 120,000 ASNs had been allocated globally, while the number actively visible in BGP routing tables varied by dataset and vantage point.

Three types matter in practice:

Stub AS: connects to only one upstream provider. A small company with a single ISP connection. Most ASNs are stubs.
Multi-homed AS: connects to two or more upstreams for redundancy. A mid-size enterprise with connections to both Cogent and Lumen.
Transit AS: carries traffic between other autonomous systems. The backbone providers (AS3356 Lumen, AS2914 NTT, AS174 Cogent) that form the internet's core routing infrastructure. The glue that holds all of this together is BGP (Border Gateway Protocol). When an AS wants the internet to know about its IP prefixes, it announces them via BGP. Each announcement includes an AS-PATH: the sequence of ASNs that traffic traverses to reach the prefix. Routers use the AS-PATH to choose the best route, typically the shortest one.

A concrete example: your browser requests a page hosted in Frankfurt. Your ISP (say, AS7922 Comcast) checks its BGP table and finds that the shortest path to the destination prefix goes through AS3356 (Lumen) to AS24940 (Hetzner). Three ASNs, three AS-path hops.

Why Security Engineers Care About ASN Data

Threat Attribution Beyond the IP

An IP address can change hands hourly in cloud environments. An ASN identifies the network operator, which is far more stable. When you see a cluster of malicious requests coming from 5 different IPs, they might all resolve to the same ASN. That's not 5 separate actors; that's one network.

Suppose your WAF flags credential stuffing attempts from 185.220.101.x. You look up the ASN: AS205100, F3 Netze e.V., a Tor exit node operator in Germany. That single fact reframes the incident. You're not dealing with a compromised residential user; you're dealing with traffic deliberately routed through an anonymization network. The response changes from "investigate the user" to "rate-limit the network."

Tip: The type field in ASN data is your first filter. HOSTING and ISP ASNs produce most bot traffic. EDUCATION and BUSINESS ASNs are more likely to be legitimate. It's a rough heuristic, not a rule, but it cuts noise.

ASN-Based Blocking and Allowlisting

Individual IP blocking is a game of whack-a-mole. Attackers rotate IPs constantly. ASN-level blocking is coarser but more durable: if an autonomous system consistently sources malicious traffic, blocking it at the network level eliminates entire IP ranges at once.

A practical example: hosting providers like Hetzner (AS24940), OVHcloud (AS16276), and DigitalOcean (AS14061) are popular with both legitimate developers and attackers. You probably can't block them outright. But you can apply stricter rate limits and CAPTCHA challenges to traffic originating from hosting ASNs while letting residential ISP ASNs through with less friction. The ASN's type field (ISP vs HOSTING vs BUSINESS) enables this segmentation without maintaining manual IP lists.

Infrastructure Mapping with Network Topology

Basic ASN lookups tell you who operates a network. Topology data, upstream and downstream relationships, tells you how that network connects to the rest of the internet.

When investigating a phishing campaign, you find the domain resolves to an IP in AS64500 (a small hosting provider). Pulling the downstream data reveals that AS64500 has three downstream ASNs, two of which have shown up in threat feeds before. That's not a coincidence; it's infrastructure reuse across campaigns. The upstream data shows AS64500 buys transit from a single provider, which gives you an escalation path for abuse reports.

This kind of analysis is impossible with IP-level data alone. It requires the network topology layer that ASN data provides.

SIEM and Log Enrichment

Raw firewall logs are walls of IP addresses. Enriching each IP with its ASN, organization name, and network type transforms those logs from "1,000 IPs hit the login endpoint" into "380 of those IPs belong to three hosting providers, 50 belong to Tor exit ASNs, and the rest are residential ISPs." That's actionable intelligence.

Adding ASN data to your SIEM pipeline lets you aggregate by network operator instead of individual IP. When AS16276 (OVHcloud) shows up in 200 failed login events across 40 different IPs, that's one signal, not 40.

How to Query ASN Data Programmatically

What You Need

An API key from ipgeolocation.io
curl (for quick lookups), Python 3.8+, or Node.js 18+ Alternatives exist in this space. Team Cymru, HackerTarget, ipinfo, and MaxMind GeoLite2 all offer ASN data. This tutorial uses ipgeolocation.io's ASN endpoint because it returns ASN details plus routes, peers, upstreams, and downstreams in a single call, which is the part that matters for security analysis.

Pitfall: ASN data from the unified IP geolocation endpoint on most providers gives you the basic AS number and organization. If you need route prefixes and peering relationships, you need a dedicated ASN endpoint or a separate BGP data source.

curl

Set your API key as an environment variable first:

export IPGEO_API_KEY="your_api_key_here"

The examples below pipe output to jq for readability. Drop | jq . if you don't have it installed.

The fastest way to look up an IP's ASN:

curl -s "https://api.ipgeolocation.io/v3/asn?apiKey=${IPGEO_API_KEY}&ip=8.8.8.8" | jq .

Response:

{
  "ip": "8.8.8.8",
  "asn": {
    "as_number": "AS15169",
    "organization": "Google LLC",
    "country": "US",
    "type": "BUSINESS",
    "domain": "google.com",
    "date_allocated": "2000-03-10",
    "asn_name": "GOOGLE",
    "allocation_status": "ASSIGNED",
    "num_of_ipv4_routes": "1737",
    "num_of_ipv6_routes": "727",
    "rir": "ARIN"
  }
}

Route counts and peering relationships change over time as BGP data evolves. The values above reflect a point-in-time snapshot.

To pull network topology for a specific ASN:

curl -s "https://api.ipgeolocation.io/v3/asn?apiKey=${IPGEO_API_KEY}&asn=AS24940&include=peers,upstreams,downstreams,routes" | jq .

This returns the full picture: every IP prefix the AS announces, who it peers with, who provides its upstream transit, and who sits downstream. For AS24940 (Hetzner), the response includes announced IPv4 and IPv6 routes, plus the transit and peering relationships that connect Hetzner to the rest of the internet.

Python

Install the requests library if you haven't already:

pip install requests

import os
import requests

API_KEY = os.environ.get("IPGEO_API_KEY")
if not API_KEY:
    raise RuntimeError("Missing IPGEO_API_KEY environment variable")

BASE_URL = "https://api.ipgeolocation.io/v3/asn"

def lookup_ip_asn(ip_address):
    """Resolve an IP to its ASN and network details."""
    try:
        resp = requests.get(
            BASE_URL,
            params={"apiKey": API_KEY, "ip": ip_address},
            timeout=(2.0, 5.0),
        )
        resp.raise_for_status()
        data = resp.json()

        asn_data = data.get("asn", {})
        return {
            "ip": data.get("ip"),
            "as_number": asn_data.get("as_number"),
            "organization": asn_data.get("organization"),
            "type": asn_data.get("type"),
            "country": asn_data.get("country"),
            "rir": asn_data.get("rir"),
        }
    except requests.exceptions.Timeout:
        print(f"Timeout looking up ASN for {ip_address}")
        return None
    except requests.exceptions.RequestException as e:
        print(f"ASN lookup failed for {ip_address}: {e}")
        return None


def get_asn_topology(as_number):
    """Pull full network topology for an ASN: routes, peers, upstreams, downstreams."""
    try:
        resp = requests.get(
            BASE_URL,
            params={
                "apiKey": API_KEY,
                "asn": as_number,
                "include": "routes,peers,upstreams,downstreams",
            },
            timeout=(2.0, 10.0),
        )
        resp.raise_for_status()
        return resp.json().get("asn", {})
    except requests.exceptions.RequestException as e:
        print(f"Topology lookup failed for {as_number}: {e}")
        return None


if __name__ == "__main__":
    # Basic IP-to-ASN lookup
    result = lookup_ip_asn("8.8.8.8")
    if result:
        print(f"{result['ip']} -> {result['as_number']} ({result['organization']}, {result['type']})")

    # Full topology for a hosting provider
    topology = get_asn_topology("AS24940")
    if topology:
        routes = topology.get("routes", [])
        peers = topology.get("peers", [])
        upstreams = topology.get("upstreams", [])
        downstreams = topology.get("downstreams", [])
        print(f"AS24940 announces {len(routes)} routes, peers with {len(peers)} ASNs")
        print(f"  Upstreams: {[u['as_number'] for u in upstreams]}")
        print(f"  Downstreams: {[d['as_number'] for d in downstreams]}")

The two functions cover the two core use cases: lookup_ip_asn for enriching individual IPs in a log pipeline, and get_asn_topology for deeper investigation when you need to understand a network's structure.

A longer timeout on the topology call (10 seconds vs 5) accounts for the larger response payload when routes and peering data are included.

JavaScript (Node.js)

const API_KEY = process.env.IPGEO_API_KEY;
if (!API_KEY) {
  throw new Error("Missing IPGEO_API_KEY environment variable");
}

const BASE_URL = "https://api.ipgeolocation.io/v3/asn";

async function lookupIpAsn(ipAddress) {
  const url = `${BASE_URL}?apiKey=${API_KEY}&ip=${encodeURIComponent(ipAddress)}`;

  try {
    const resp = await fetch(url, { signal: AbortSignal.timeout(5000) });

    if (!resp.ok) {
      console.error(`ASN lookup returned ${resp.status} for ${ipAddress}`);
      return null;
    }

    const data = await resp.json();
    const asn = data.asn ?? {};

    return {
      ip: data.ip,
      asNumber: asn.as_number,
      organization: asn.organization,
      type: asn.type,
      country: asn.country,
      rir: asn.rir,
    };
  } catch (err) {
    if (err.name === "TimeoutError") {
      console.error(`Timeout looking up ASN for ${ipAddress}`);
    } else {
      console.error(`ASN lookup failed for ${ipAddress}:`, err.message);
    }
    return null;
  }
}

async function getAsnTopology(asNumber) {
  const url = `${BASE_URL}?apiKey=${API_KEY}&asn=${encodeURIComponent(asNumber)}&include=routes,peers,upstreams,downstreams`;

  try {
    const resp = await fetch(url, { signal: AbortSignal.timeout(10000) });

    if (!resp.ok) {
      console.error(`Topology lookup returned ${resp.status} for ${asNumber}`);
      return null;
    }

    const data = await resp.json();
    return data.asn ?? {};
  } catch (err) {
    console.error(`Topology lookup failed for ${asNumber}:`, err.message);
    return null;
  }
}

// Usage
const result = await lookupIpAsn("8.8.8.8");
if (result) {
  console.log(`${result.ip} -> ${result.asNumber} (${result.organization}, ${result.type})`);
}

const topo = await getAsnTopology("AS24940");
if (topo) {
  const routes = topo.routes ?? [];
  const peers = topo.peers ?? [];
  console.log(`AS24940 announces ${routes.length} routes, peers with ${peers.length} ASNs`);
}

Both functions mirror the Python version. AbortSignal.timeout(5000) prevents hung connections from blocking your pipeline. The ?? (nullish coalescing) operator handles missing fields without throwing.

Reading the Response: What Each Field Tells You

The basic ASN response contains eleven fields. Here's what matters for security work:

as_number: The ASN itself, formatted with the "AS" prefix (e.g., "AS15169"). This is the identifier you'll use for blocking rules, SIEM correlation, and threat feed matching.

organization: The entity registered with the RIR as the AS holder. For cloud providers, this is the provider, not the customer. AS16509 is "Amazon.com, Inc." even though the IP you're investigating belongs to a fintech startup running on AWS.

type: One of ISP, HOSTING, BUSINESS, or EDUCATION. This is your first-pass risk signal. HOSTING ASNs produce a disproportionate share of automated attacks. ISP ASNs carry mostly residential traffic. EDUCATION ASNs are universities.

country: ISO 3166-1 alpha-2 country code for the AS registration. Not necessarily where the traffic originates (a Hetzner server in Finland still shows "country": "DE" because Hetzner is registered in Germany).

rir: Which Regional Internet Registry manages the ASN. Useful for abuse reporting: RIPE NCC has different abuse processes than ARIN.

routes (with include=routes): The IP prefixes this AS announces to the internet. This is the AS's footprint. If you see malicious traffic from 5 IPs and all fall within prefixes announced by the same ASN, that confirms you're dealing with one network.

peers, upstreams, downstreams (with include=peers,upstreams,downstreams): The network's BGP relationships. Upstreams are transit providers (who the AS pays for internet access). Downstreams are customer networks. Peers are networks exchanging traffic directly. For investigation, downstreams are particularly interesting: they reveal smaller networks hiding behind a hosting provider's ASN.

Putting It Together: An Investigation Walkthrough

You pull your morning alerts and find 47 failed SSH login attempts across 3 IPs overnight: 185.220.101.34, 185.220.101.42, and 185.220.101.52. Different IPs, same /24 range, but you want to confirm this is one actor.

Step 1: Look up the ASN for any of the three IPs. They all resolve to AS205100, F3 Netze e.V., registered in Germany. The organization name and the related prefix data point to Tor-exit traffic. That reframes the incident immediately: you're not dealing with a compromised residential user, you're dealing with traffic deliberately routed through an anonymization network.

Step 2: Pull the topology with include=routes,upstreams. The routes show a small number of prefixes (the 185.220.101.0/24 range among them). The upstreams show two transit providers. A stub-like topology for what is effectively a single-purpose network.

Step 3: Check your SIEM for historical traffic from AS205100. You find it appears in 12 previous incidents over the past 90 days, all brute-force attempts. That's a pattern.

Step 4: Decision. Hard-blocking AS205100 is reasonable here because it's a single-purpose Tor exit network, and your service has no legitimate users routing through Tor exits. For a multi-purpose hosting ASN like Hetzner or DigitalOcean, you'd rate-limit instead of block.

The whole investigation took 4 API calls and 3 minutes. Without ASN data, you'd have looked up 3 IPs individually, found they're "in Germany," and missed the network-level pattern entirely.

Caching and Performance Notes

ASN assignments change infrequently. An IP's ASN changes when the IP block is sold or reallocated, which happens on the order of months or years, not hours. A 24-hour TTL on cached ASN lookups is aggressive enough for most security use cases without wasting quota on redundant calls.

For high-volume enrichment (processing millions of log entries), consider a local database instead of per-request API calls. MMDB-format ASN databases eliminate network latency entirely and support the same lookup patterns. The trade-off is update frequency: you're working with a daily snapshot instead of real-time data. For most enrichment pipelines, that's acceptable.

When the ASN API is unreachable, fail open. ASN enrichment adds context but isn't load-bearing for most security decisions. Log the unenriched event and backfill later rather than dropping traffic or blocking alerts because the lookup timed out.

A Few Extra Notes

Private ASNs exist. The ranges 64512-65534 (16-bit) and 4200000000-4294967294 (32-bit) are reserved for private use. These are used internally by organizations with complex routing but should never appear in public BGP tables. If you see a private ASN in external traffic, something is misconfigured upstream, and that's worth investigating on its own.

ASN data is one signal, not a verdict. AS16509 (Amazon AWS) hosts both legitimate SaaS products and attack infrastructure. Blocking it would break half the internet. Use ASN data to inform decisions (add friction, increase logging, require CAPTCHA), not to make them unilaterally.

The organization field can mislead. Cloud providers sublease IP ranges. The ASN registrant is Amazon, Google, or Microsoft, but the actual user of the IP is whoever rented that instance. For cloud ASNs, pair ASN data with reverse DNS, TLS certificate inspection, or company-level enrichment to get closer to the real operator.

For a deeper reference on autonomous systems, BGP routing, and ASN assignment history, the ARIN ASN guide and the ipgeolocation.io ASN guide both cover the conceptual side in more depth than this tutorial has room for.

Add IP Fraud Scoring to Your Auth Flow

ABDULLAH AFZAL — Tue, 12 May 2026 11:01:05 +0000

Credential stuffing bots hit login endpoints at thousands of requests per minute, rotating through IP addresses as they go. By the time your rate limiter reacts, the damage is done. An IP fraud score check sits before your auth logic, scores each IP from 0 to 100 and lets you decide whether to allow, challenge, or block.

This tutorial adds that check to a Node.js/Express and Python/Flask login route. You'll also get the cURL version for testing. The whole thing takes about 30 minutes to wire up.

TL;DR

An IP fraud score is a 0-100 rating aggregating VPN/proxy/Tor detection, known attacker history, bot activity, and cloud provider flags into a single number
The dedicated /v3/security endpoint returns a structured security object: threat score, VPN/proxy/Tor/relay flags, provider names ("Nord VPN", "922 Proxy"), confidence scores, and last-seen dates
Graduated thresholds: 0-19 allow, 20-44 log and flag, 45-79 force MFA, 80-100 block
Fail-open on the API check for login routes (if the scoring API is down, let users through with logging). Fail-closed for payment endpoints.
Cache results in Redis with a 5-minute TTL to avoid per-request API calls
Code below covers cURL, Node.js/Express middleware, and Python/Flask decorator

One API call before your auth logic flags risky IPs often seen in credential stuffing, residential proxy abuse, and known attacker traffic before they hit your password check. The response includes enough detail (provider names, confidence scores, timestamps) to build graduated rules, not just a binary block.

What the Security API Returns

Most IP reputation APIs give you a handful of boolean flags: is_vpn: true, is_proxy: false, done. That tells you what the IP is, but not how confident the detection is or which provider it belongs to.

The ipgeolocation.io Security API returns a structured object per lookup: threat score, anonymization flags, provider attribution, confidence scores, and last-seen timestamps. Here's what a flagged IP actually looks like:

{
  "ip": "2.56.188.34",
  "security": {
    "threat_score": 80,
    "is_tor": false,
    "is_proxy": true,
    "proxy_provider_names": ["Zyte Proxy"],
    "proxy_confidence_score": 90,
    "proxy_last_seen": "2025-12-12",
    "is_residential_proxy": true,
    "is_vpn": true,
    "vpn_provider_names": ["Nord VPN"],
    "vpn_confidence_score": 99,
    "vpn_last_seen": "2026-01-19",
    "is_relay": false,
    "relay_provider_name": "",
    "is_anonymous": true,
    "is_known_attacker": true,
    "is_bot": false,
    "is_spam": false,
    "is_cloud_provider": true,
    "cloud_provider_name": "Packethub S.A."
  }
}

The difference matters for auth decisions. Knowing an IP is "a VPN" is less useful than knowing it's NordVPN with 99% confidence, last seen yesterday, and also flagged as a known attacker with a threat score of 80. The first gives you a boolean. The second gives you a policy.

is_residential_proxy is worth calling out specifically. Residential proxies route traffic through real ISP connections, so they look legitimate to basic VPN detectors. Services like 922 Proxy, Oxylabs, and Bright Data sell this access. If your fraud rules only check is_vpn and is_proxy, residential proxy traffic sails right through. The dedicated flag catches it.

Setup

You need Node.js 18+ or Python 3.8+, and an ipgeolocation.io API key with security access.

Tip: IPGeolocation, IPQS, Scamalytics, AbuseIPDB, and MaxMind minFraud all offer IP risk scoring with different pricing models, detection depth, and response shapes. I'm using ipgeolocation.io for these examples because the /v3/security endpoint returns provider attribution and confidence scores in one call, which keeps the graduated-response code clean.

Set your API key as an environment variable. Do not hardcode it.

export IPGEO_API_KEY="your_api_key_here"

Install the dependencies you'll need:

# Node.js
npm install express ioredis

# Python
pip install flask requests

Test with cURL First

Before writing middleware, call the endpoint directly to see the response shape for a known IP:

curl -s "https://api.ipgeolocation.io/v3/security?apiKey=${IPGEO_API_KEY}&ip=8.8.8.8" | python3 -m json.tool

For 8.8.8.8 (Google Public DNS), you'll get a low threat score and is_cloud_provider: true with cloud_provider_name: "Google LLC". That's a clean IP doing exactly what you'd expect.

Try it with a known proxy or Tor exit IP if you have one handy. The threat_score jump and the flag combination tells you whether your thresholds will catch what you care about.

Node.js/Express Middleware

Here's the middleware. It runs before your login handler, checks the IP against the Security API, and attaches the score to the request object so downstream handlers can act on it.

// ip-risk-middleware.js
const API_KEY = process.env.IPGEO_API_KEY;
const SECURITY_URL = 'https://api.ipgeolocation.io/v3/security';

if (!API_KEY) {
  throw new Error('Missing IPGEO_API_KEY environment variable');
}

async function ipRiskCheck(req, res, next) {
  // Trust the first X-Forwarded-For entry if behind a reverse proxy.
  // Verify your proxy sets this correctly; spoofable if not.
  const clientIp =
    req.headers['x-forwarded-for']?.split(',')[0]?.trim() ||
    req.socket.remoteAddress;

  try {
    const response = await fetch(
      `${SECURITY_URL}?apiKey=${API_KEY}&ip=${clientIp}`,
      { signal: AbortSignal.timeout(1500) } // 1.5s timeout; don't let a slow API stall login
    );

    if (!response.ok) {
      // API error: fail open for login routes, log the failure
      console.error(`IP risk API returned ${response.status} for ${clientIp}`);
      req.ipRisk = { score: 0, flags: {}, failedOpen: true };
      return next();
    }

    const data = await response.json();
    const security = data.security ?? {};
    const score = security.threat_score ?? 0;

    // Attach the full security object for downstream handlers
    req.ipRisk = {
      score,
      flags: security,
      ip: clientIp,
    };

    // Graduated response based on threat score
    if (score >= 80) {
      console.warn(`BLOCKED: IP ${clientIp} scored ${score}`, {
        vpn: security.is_vpn,
        proxy: security.is_proxy,
        attacker: security.is_known_attacker,
      });
      return res.status(403).json({ error: 'Request blocked' });
    }

    if (score >= 45) {
      // Elevated risk: force MFA regardless of account settings
      req.requireMfa = true;
    }

    next();
  } catch (err) {
    // Network timeout or fetch failure: fail open, log it
    console.error(`IP risk check failed for ${clientIp}: ${err.message}`);
    req.ipRisk = { score: 0, flags: {}, failedOpen: true };
    next();
  }
}

module.exports = { ipRiskCheck };

Wire it into your login route:

const express = require('express');
const { ipRiskCheck } = require('./ip-risk-middleware');

const app = express();
app.use(express.json());

// Apply the risk check to auth routes only.
// Running it on every route burns API quota on static assets.
app.post('/api/login', ipRiskCheck, (req, res) => {
  const { score, flags, failedOpen } = req.ipRisk;

  // Log every auth attempt with its risk score for later threshold tuning
  console.log(`Login attempt from ${req.ipRisk.ip}: score=${score}`, {
    failedOpen,
    vpn: flags.is_vpn,
    proxy: flags.is_proxy,
    residential_proxy: flags.is_residential_proxy,
    tor: flags.is_tor,
  });

  if (req.requireMfa) {
    return res.status(200).json({
      mfaRequired: true,
      reason: 'elevated_ip_risk',
    });
  }

  // Normal login flow continues here
  res.json({ success: true });
});

app.listen(3000, () => console.log('Running on :3000'));

A few things to note. AbortSignal.timeout(1500) caps the API call at 1.5 seconds. IPGeolocation.io's public status page reports low average API response times, so 1.5 seconds is intentionally conservative. Network hiccups still happen, and a stalled risk check should never block a user from logging in. The middleware fails open: if the API is unreachable, the user gets through with failedOpen: true logged so you can audit later.

If you're behind Cloudflare, Nginx, or an AWS ALB, make sure trust proxy is configured in Express (app.set('trust proxy', 1)) so Express resolves the client IP from X-Forwarded-For correctly. Without it, req.socket.remoteAddress gives you the proxy's IP, not the client's. Only trust X-Forwarded-For when your edge proxy overwrites incoming forwarded headers. Never trust a client-supplied forwarded header directly.

Python/Flask Equivalent

Same logic, different runtime. This uses a decorator pattern so you can apply it selectively to routes.

# ip_risk.py
import os
import functools
import requests
from flask import request, jsonify, g

API_KEY = os.environ.get('IPGEO_API_KEY')
SECURITY_URL = 'https://api.ipgeolocation.io/v3/security'

if not API_KEY:
    raise RuntimeError('Missing IPGEO_API_KEY environment variable')


def check_ip_risk(f):
    @functools.wraps(f)
    def decorated(*args, **kwargs):
        # Behind a reverse proxy, X-Forwarded-For holds the real client IP.
        # Take the first entry; later entries are intermediate proxies.
        client_ip = (
            request.headers.get('X-Forwarded-For', '').split(',')[0].strip()
            or request.remote_addr
        )

        try:
            resp = requests.get(
                SECURITY_URL,
                params={'apiKey': API_KEY, 'ip': client_ip},
                timeout=(1.0, 1.5),  # 1s connect, 1.5s read
            )
            resp.raise_for_status()
            data = resp.json()
            security = data.get('security', {})
            score = security.get('threat_score', 0)
        except (requests.RequestException, ValueError) as err:
            # Fail open: API down should not lock users out of login
            print(f'IP risk check failed for {client_ip}: {err}')
            g.ip_risk = {'score': 0, 'flags': {}, 'failed_open': True}
            return f(*args, **kwargs)

        g.ip_risk = {
            'score': score,
            'flags': security,
            'ip': client_ip,
            'failed_open': False,
        }

        if score >= 80:
            print(f'BLOCKED: {client_ip} scored {score}')
            return jsonify({'error': 'Request blocked'}), 403

        if score >= 45:
            g.require_mfa = True

        return f(*args, **kwargs)

    return decorated

Apply it to your login route:

from flask import Flask, g, jsonify
from ip_risk import check_ip_risk

app = Flask(__name__)


@app.route('/api/login', methods=['POST'])
@check_ip_risk
def login():
    risk = g.ip_risk

    app.logger.info(
        'Login attempt from %s: score=%d, failed_open=%s',
        risk.get('ip'),
        risk['score'],
        risk.get('failed_open'),
    )

    if getattr(g, 'require_mfa', False):
        return jsonify({'mfa_required': True, 'reason': 'elevated_ip_risk'})

    # Normal login flow
    return jsonify({'success': True})

The timeout=(1.0, 1.5) tuple sets a 1-second connection timeout and 1.5-second read timeout. Python's requests library hangs indefinitely without an explicit timeout, which is the kind of bug that doesn't surface until your login endpoint stops responding at 2 AM.

Cache Results with Redis

Calling the Security API on every single login request works fine under moderate traffic, but it's wasteful. An IP's threat score doesn't change second-to-second. A 5-minute Redis cache cuts your API usage dramatically without meaningfully delaying threat detection.

// Add to ip-risk-middleware.js
const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_URL || 'redis://localhost:6379');

const CACHE_TTL = 300; // 5 minutes in seconds

async function getCachedRisk(ip) {
  try {
    const cached = await redis.get(`ip-risk:${ip}`);
    return cached ? JSON.parse(cached) : null;
  } catch {
    return null; // Redis down: skip cache, hit API
  }
}

async function setCachedRisk(ip, security) {
  try {
    await redis.set(
      `ip-risk:${ip}`,
      JSON.stringify(security),
      'EX',
      CACHE_TTL
    );
  } catch {
    // Cache write failure is non-critical; log and move on
  }
}

Then in the middleware, check the cache before calling the API:

// Inside ipRiskCheck, before the fetch call:
const cached = await getCachedRisk(clientIp);
if (cached) {
  req.ipRisk = { score: cached.threat_score ?? 0, flags: cached, ip: clientIp };
  // Apply the same threshold logic as the non-cached path
  if (cached.threat_score >= 80) {
    return res.status(403).json({ error: 'Request blocked' });
  }
  if (cached.threat_score >= 45) {
    req.requireMfa = true;
  }
  return next();
}
// ...existing fetch call, then after parsing:
await setCachedRisk(clientIp, security);

Five minutes is a reasonable default. If you're seeing active attacks that rotate IPs faster than that, drop it to 60 seconds. If your traffic is low enough that you're under quota anyway, skip the cache entirely and keep the code simpler.

Setting Your Fraud Score Thresholds

The threshold bands I've used above are based on what ipgeolocation.io documents:

0-19: Low risk. Clean residential IP, no flags. Allow normally.
20-44: Some signals. Maybe a datacenter IP or a consumer VPN. Log it, maybe flag for review, but don't add friction yet.
45-79: Elevated. Multiple flags firing, or a known proxy service. Force MFA. A legitimate user clears MFA in seconds. A bot doesn't.
80-100: High confidence. Known attacker, active proxy with provider attribution, or multiple overlapping anonymization signals. Block the request.

Start permissive. Deploy the middleware in log-only mode (no blocking, no MFA forcing) for a week. Look at the score distribution for your actual traffic. If 10% of your legitimate users come through corporate VPNs and score 30-40, you don't want your MFA threshold at 30. Tune based on your data, not on defaults.

For payment endpoints, flip the logic: fail-closed instead of fail-open. If the scoring API is down and you can't verify the IP, hold the transaction for manual review rather than letting it through. The risk calculus is different when money moves.

Edge Cases Worth Handling

Corporate NAT and shared IPs. A large office with 500 employees behind one public IP looks like a single entity to any IP-based system. If someone on that network triggered a flag last week, the whole office inherits it. Graduated responses handle this better than hard blocks. Score 35 with MFA is a minor inconvenience for a real employee. A hard block at the same score locks out the whole building.

VPN users who aren't malicious. Journalists, security researchers, and privacy-conscious developers use commercial VPNs daily. The is_vpn: true flag alone shouldn't trigger a block. Pair it with threat_score: a NordVPN IP with a score of 15 is a privacy-conscious user. The same VPN range with a score of 75 and is_known_attacker: true is a different story.

iCloud Private Relay and similar services. Apple's iCloud Private Relay, Cloudflare WARP, and Chrome's IP Protection are growing. The is_relay flag distinguishes these from traditional VPNs. Blocking relay traffic means blocking a meaningful chunk of iOS users. Unless you have a specific reason (geo-compliance, content licensing), treat relay IPs as low-risk.

Cloud provider IPs. Your CI/CD pipeline, webhook senders, and monitoring services all originate from AWS, GCP, or Azure ranges. The is_cloud_provider flag with cloud_provider_name helps you whitelist known sources. A login attempt from "Google LLC" infrastructure is suspicious. A health check from the same range is expected.

GDPR and IP logging. If you serve EU users, storing IP addresses with threat scores counts as personal data processing under GDPR. Set a retention policy (30-90 days for security logs is defensible), document the legitimate interest basis, and make sure your privacy policy covers it.

Wrapping Up

Drop the middleware into your auth routes, deploy in log-only mode for a week, and look at your actual score distribution before turning on the blocks. The thresholds above are starting points. Your traffic patterns will tell you where to tighten.

For high-traffic services, add the Redis cache from the start. For payment flows, switch to fail-closed and hold transactions when the API is unreachable. When traffic outgrows the API tier, batch analysis with the bulk endpoint (up to 50,000 IPs per POST) handles post-incident forensics without burning your real-time quota.