IP Intelligence at the Edge: Real-Time Risk Decisions with Cloudflare Workers, WAF, and API Gateways

Why Move IP Intelligence to the Edge

The standard architecture for IP-based risk evaluation looks like this: user sends a request, your application server receives it, extracts the IP, calls an external geolocation API, waits 30-200ms for the response, then makes an allow/block decision. This works, but it has three problems:

Three Edge Enforcement Patterns

There is no single "right" architecture. The best approach depends on your existing infrastructure, your latency budget, and the depth of IP analysis you need. Here are three patterns, from simplest to most sophisticated:

# Cloudflare WAF Rule (via API)
# Block traffic from flagged countries + VPN
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/rulesets" \
  -H "Authorization: Bearer TOKEN" \
  -d '{
    "name": "block-vpn-high-risk",
    "kind": "zone",
    "phase": "http_request_firewall_custom",
    "rules": [{
      "expression": "ip.geoip.country in {\"XX\" \"YY\"} and cf.threat_score gt 20",
      "action": "block",
      "description": "Block VPN traffic from high-risk regions"
    }]
  }'

// Cloudflare Worker: Edge IP risk evaluation
export default {
  async fetch(request: Request): Promise<Response> {
    const clientIp = request.headers.get('cf-connecting-ip');
    if (!clientIp) return fetch(request);

    const apiKey = 'YOUR_API_KEY';
    const apiBase = 'https://ip-info.app/api/v1/geolocate';

    try {
      const resp = await fetch(
        `${apiBase}/${clientIp}`,
        { headers: { 'x-api-key': apiKey } }
      );
      const data = await resp.json();

      if (data.isVPN) {
        return new Response('Access denied: VPN detected',
          { status: 403 });
      }

      if (data.threatLevel === 'high') {
        return Response.redirect(
          new URL('/challenge?reason=high_risk', request.url)
        );
      }

      // Attach intelligence as headers
      const newHeaders = new Headers(request.headers);
      newHeaders.set('X-IP-Country', data.countryCode);
      newHeaders.set('X-IP-ASN', String(data.asn));
      newHeaders.set('X-IP-Threat', data.threatLevel || 'unknown');

      return fetch(request, { headers: newHeaders });
    } catch (err) {
      return fetch(request); // Fail open
    }
  },
};

// API Gateway plugin pattern (pseudo-code)
async function ipRiskPolicy(request, response) {
  const ip = request.ip;
  const geo = await ipIntelClient.lookup(ip);

  switch (geo.threatLevel) {
    case 'critical':
      return response.block(403, 'Threat IP detected');
    case 'high':
      return response.challenge('Verify identity');
    case 'medium':
      // Allow with strict rate limiting
      response.setHeader('X-RateLimit-Limit', '10');
      break;
    case 'low':
      // Enrich and pass through
      response.setHeader('X-User-Country', geo.countryCode);
      response.setHeader('X-User-ISP', geo.aso);
      break;
  }

  // Log for SIEM / analytics pipeline
  await analytics.track({
    ip, country: geo.countryCode,
    isVPN: geo.isVPN, threat: geo.threatLevel,
    asn: geo.asn, path: request.path,
  });
}

Handling VPN and Proxy Traffic at the Edge

Blocking all VPN traffic is tempting but dangerous. A significant share of legitimate users connects through corporate VPNs, mobile carrier NAT pools, or privacy services like Apple Private Relay and Cloudflare WARP. A blanket VPN block alienates real customers — particularly in enterprise and privacy-conscious markets.

The practical approach is a stepped policy that combines multiple IP signals rather than relying on a single binary flag:

Keeping Edge Latency Under 50ms

The biggest latency risk in edge IP intelligence is the external API call. Here are proven strategies to keep total decision time within a tight budget:

Where Edge IP Intelligence Creates the Most Value