keen marsh
Hey everyone!
I’m building a Next.js app deployed on Vercel with Cloudflare in front and exploring an edge/app deception feature.
Goal: apply this behavior to suspicious requests for non‑existing resources (anti‑fuzzing / anti‑recon on 404-ish paths), not to normal production content or crawlers.
Looking for pointers, tutorials, or prior experience implementing this (edge vs middleware). The system I’m imagining should synthesize per‑request randomness for flagged non‑existent requests, including:
- randomized response time (small jitter/delays)
- randomized response length (variable body sizes / padding)
- randomized HTTP status code (randomly 2xx/3xx/4xx/5xx etc..)
- randomized headers (vary Server, Content-Type, extra noise headers, Location for 3xx, etc.)
- randomized HTTP request method handling (e.g., different behaviors for GET/POST/OPTIONS when probing)
- a unique session ID header per request (not time-based; unique value for each request)
- logging/telemetry that flags synthesized responses and supports escalation (tarpit/block)
- safe whitelists for crawlers/health checks and strict cache-control (
no-store) to avoid poisoning CDN caches
Stack constraints: Next.js on Vercel (prefer Edge Middleware for observability) + Cloudflare (prefer Workers for edge interception). Interested in real-world gotchas (SEO, caching, monitoring, Vercel/Cloudflare interplay), and any step-by-step guides, sample architectures, or PoCs you’ve used.
For this kind of deception / anti-fuzzing setup, what do you think is the best approach:
- Next.js middleware handling it on Vercel front
- Cloudflare Workers handling it at the edge
- Cloudflare hybrid approach (both as vercel front, and back)
- Cloudflare signals + Vercel middleware
- Or something else entirely
Curious to hear real-world pros/cons and trade-offs from people who have implemented similar features.
Appreciate links to tutorials, blog posts, or short writeups, thanks!
glass hare