How to add security deception features (nextjs/vercel and cloudflare)
Unanswered
Pip gall wasp posted this in #help-forum
Pip gall waspOP
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 (
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!
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 cachesStack 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!
1 Reply
Pip gall waspOP
PS: I’ve already implemented the randomized-response idea in Vercel Edge Middleware, but I’m running into a practical problem: the current flow issues a 307 redirect first, then the redirected request returns a randomized body/status/headers. That means an attacker can trivially filter by the initial
307
and ignore the randomized body, effectively bypassing the deception.