I Built a Prompt That Makes AI Agents Harden Any Web App Against Bot Abuse — Here's the Full System, the Tests, and What I Learned

How suspicious traffic on my production sites led me to build a universal, framework-agnostic abuse deterrence system that any AI coding agent can implement — and the verification tests that proved my first attempt failed.

Reading time: ~20 minutes

The Problem: Your Site Is Under Attack and You Don't Even Know It

I had two production web applications running on Vercel:

• Vocab Top — an AI-powered vocabulary learning platform
• Prompt Builder — a prompt engineering workspace with 7,000+ templates

Both were live, indexed by Google, getting real users. Then I checked my Vercel analytics and saw something wrong: an abnormal spike in requests, unusual traffic patterns, and server function invocations that didn't correlate with actual user activity. Someone — or more likely some*thing* — was hammering my sites.

This is not an uncommon story. If you've deployed a web application with public API routes, you've almost certainly experienced this. Bots scrape your content, automated scripts flood your endpoints, and headless browsers impersonate real users to abuse your services. The cost isn't just bandwidth — it's inflated hosting bills, degraded performance for real users, polluted analytics, and potential data exfiltration.

I decided to fix it systematically. Not with a one-off patch, but with a reusable system I could apply to every site I build — past, present, and future.

The Approach: A Universal Prompt for AI Coding Agents

Modern AI coding agents — Claude, GPT, Gemini, Copilot — can analyze a codebase and implement complex changes across multiple files. But they need precise instructions. Vague requests like "add security" produce vague results. I learned this the hard way.

My first attempt was framework-specific: I told the AI agent to "add bot protection to my Next.js app on Vercel." It partially worked — it added some security headers in next.config.mjs and a vercel.json with function limits. But it completely skipped the most critical layers: the middleware that actually blocks bots, the rate limiter, and the honeypot traps. When I tested the live sites, every single bot User-Agent sailed through with a 200 OK.

The lesson: you need to be exhaustive and explicit. The AI agent will do exactly what you describe — nothing more, nothing less. If your prompt says "add security headers," you'll get security headers and nothing else.

So I built a universal prompt that leaves nothing to interpretation. It works with any framework, any hosting platform, any language. The AI agent's first job is to analyze your stack, then implement four distinct defense layers adapted to whatever it finds.

The 4-Layer Defense System

Before diving into the prompt itself, let me explain what each layer does and why all four are necessary. No single layer is sufficient on its own — attackers who bypass one will hit the next.

Layer 1 — Request Interceptor (Middleware)

This is the front door. A middleware function that runs before any route handler, inspecting every incoming request. It implements three checks:

Bot User-Agent Blocking: A regex that matches known non-browser User-Agent strings — python-requests, curl, scrapy, puppeteer, selenium, postman, axios, node-fetch, and dozens more. When matched, the server returns a silent 404 (not 403) so the bot receives zero feedback that it's being filtered. Critically, legitimate search crawlers like Googlebot and Bingbot are excluded from blocking — you don't want to tank your SEO.

Origin/Referer Enforcement on API Routes: For any POST request to an API endpoint, the middleware verifies that the Origin or Referer header matches your production domain. If someone calls your API directly from curl, Postman, or a Python script, there's no matching Origin header — the request gets rejected with 403. This is a simple but remarkably effective barrier against programmatic API abuse.

Per-IP Rate Limiting: A sliding-window rate limiter keyed by the client's IP address. Default: 30 requests per IP per 60-second window. When exceeded, the server returns 429 Too Many Requests with a Retry-After header. This stops flood attacks and brute-force attempts without affecting normal users.

Layer 2 — Hardened API Routes

Even if a request gets past the middleware (e.g., it has a valid browser User-Agent and the correct Origin header), the API route itself has additional guards:

1. Content-Type check — reject anything that isn't application/json with 415 Unsupported Media Type
2. Body size limit — reject payloads larger than 8 KB with 413 Payload Too Large
3. Origin re-check — defense-in-depth
4. JSON parsing — wrapped in try/catch; return 400 on malformed JSON
5. Required field validation — return 400 if expected fields are missing
6. Input sanitization — max character length per field, HTML entity escaping
7. Format validation — whitelist regex for structured fields like phone numbers and emails

This layered validation means that even if an attacker spoofs the right headers, they still need to send a properly formatted, correctly typed, reasonably sized JSON payload with valid field values. The attack surface shrinks dramatically.

Layer 3 — Honeypot Trap

This targets bots that render your frontend and auto-fill forms — the ones sophisticated enough to bypass User-Agent checks. The technique is simple and invisible to real users:

Add a hidden input field to every form. It has a plausible name like website (which bots love to auto-fill), but it's styled to be invisible: position: absolute; opacity: 0; height: 0; pointer-events: none. Real users never see it, never fill it. Bots, which parse the DOM and fill every field, populate it automatically.

At the top of the form submission handler, you check: if the honeypot field has any value, silently return. No error message, no toast notification, no console log. The bot thinks its submission succeeded. Zero feedback.

The key detail: don't use display: none or visibility: hidden — modern bots detect those. The combination of opacity: 0 with pointer-events: none is functionally invisible but passes bot detection heuristics.

Layer 4 — Hosting & Deployment Configuration

The final layer hardens the deployment itself:

• API routes: Cache-Control: no-store prevents the CDN from caching API responses (which could leak user data)
• Security headers: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy, Strict-Transport-Security, Referrer-Policy, Permissions-Policy
• Source maps: Either disabled in production or marked with X-Robots-Tag: noindex
• Function timeouts: Set as low as reasonable (e.g., 10 seconds) to prevent abuse from running up compute costs
• Clean URLs: Consistent URL structure to prevent path-based attacks

The Universal Prompt

Here is the complete prompt. Copy it into any AI coding agent conversation — Claude, GPT, Gemini, Cursor, Windsurf, or any other — and it will analyze your project's tech stack and implement all four layers.

Before using it: replace [REPLACE WITH YOUR DOMAIN] with your actual production URL.

My web application is experiencing suspicious traffic — bots, scrapers, or
automated abuse hitting the site with an abnormal volume of requests.

I need you to analyze the project, identify its technology stack, and implement
a multi-layered abuse deterrence system adapted to whatever framework, server,
and hosting platform you find.

My production domain is: [REPLACE WITH YOUR DOMAIN]

STEP 0 — ANALYZE THE STACK
Before writing any code, examine the project and determine:

  1. Framework (Next.js, Nuxt, SvelteKit, Express, Flask, Django, Laravel,
     plain HTML/JS, etc.)
  2. Runtime (Node.js, Python, PHP, Ruby, Go, etc.)
  3. Hosting platform (Vercel, Netlify, Cloudflare Pages/Workers, AWS, Railway,
     Render, DigitalOcean, traditional VPS, etc.)
  4. API endpoints or server routes that accept user input
  5. Forms or interactive components in the frontend that trigger those routes

Report your findings before implementing anything.

LAYER 1 — REQUEST INTERCEPTOR (Middleware / Gateway / Proxy)
Create a request interceptor that runs BEFORE any route handler. Use whatever
the framework provides natively:

  • Next.js      → middleware.js (Edge Middleware)
  • Nuxt         → server/middleware/
  • SvelteKit    → hooks.server.ts (handle hook)
  • Express      → app.use() middleware
  • Flask        → @app.before_request
  • Django       → custom middleware class
  • Laravel      → HTTP middleware
  • Cloudflare   → _middleware.ts (Pages Functions)
  • Nginx/Apache → mod_security or custom conf rules
  • Standalone   → reverse proxy rules (Caddy, Traefik, etc.)

This interceptor must implement THREE checks:

1. BOT / USER-AGENT BLOCKING
   Block requests whose User-Agent matches known non-browser clients:
   curl, wget, python-requests, python-urllib, python/, java/, go-http-client,
   ruby/, php/, perl/, axios/, node-fetch/, undici/, got/, superagent/,
   okhttp/, apache-httpclient/, aiohttp/, httpx/, postman, insomnia,
   headlesschrome, puppeteer, playwright, selenium, phantomjs, splash,
   webdriver, scrapy, mechanize, libwww-perl, lwp-trivial, zgrab, masscan,
   nmap, nikto, sqlmap, dirbuster, nuclei.

   Return a SILENT 404 (not 403) so bots don't know they're being blocked.
   Do NOT block Googlebot, Bingbot, or other legitimate search crawlers.

2. ORIGIN / REFERER ENFORCEMENT ON API ROUTES
   For any request to an API endpoint, verify that the Origin or Referer
   header matches the production domain or localhost. If neither matches,
   return 403 with a generic JSON error. This blocks direct curl/Postman/script
   access to your API.

3. PER-IP RATE LIMITING ON API ROUTES
   Implement a rate limiter keyed by the client's IP address.
   Use whatever is most natural for the stack:
     • In-memory Map with sliding window (serverless / edge)
     • Redis-backed counter (if Redis is available)
     • Framework-specific rate-limit library (express-rate-limit, etc.)
     • Platform-native feature (Cloudflare Rate Limiting, etc.)
   Default: max 30 requests per IP per 60-second window.
   Return 429 Too Many Requests with Retry-After: 60 header when exceeded.

Do NOT install new packages unless the stack has no built-in way to achieve
the above. Prefer native APIs and platform features.

LAYER 2 — HARDENED API ROUTES
For every API route that accepts POST data from users, add these guards
IN ORDER before any business logic:

  1. Content-Type check — reject anything not application/json (or the
     expected type) with 415.
  2. Body size limit — reject payloads larger than 8 KB with 413.
  3. Origin / Referer re-check — defense-in-depth even if Layer 1 checked.
  4. JSON parsing — wrap in try/catch; return 400 on failure.
  5. Required field validation — return 400 if missing.
  6. Input sanitization — define max character length per field and truncate.
     Escape or strip HTML special characters (& < >) before using values in
     any downstream service, template, or database query.
  7. Format validation — for structured fields (phone numbers, emails, IDs),
     apply a whitelist regex and return 400 if it fails.

LAYER 3 — HONEYPOT TRAP IN THE FRONTEND
In every frontend form or interactive component that triggers an API call:

  1. Add a hidden input field that real users will never see or fill:
     • name="website" (a plausible label bots auto-fill)
     • tabIndex=-1, autoComplete="off", aria-hidden="true"
     • Styled with: position absolute, opacity 0, height 0, width 0,
       pointerEvents none, overflow hidden.
     DO NOT use display:none or visibility:hidden — bots detect those.

  2. At the very top of the submit/action handler, check: if the honeypot
     field has any value, SILENTLY RETURN without doing anything.
     No error message, no toast, no console log. The bot must receive
     zero feedback that it was caught.

  Adapt this to the framework:
    • React/Vue/Svelte → state variable checked before the action
    • Plain HTML/JS    → check input value in the submit event listener
    • Server-rendered  → check the field server-side before processing

LAYER 4 — HOSTING / DEPLOYMENT CONFIGURATION
Add platform-specific configuration to reduce the attack surface:

  For Vercel → vercel.json:
    • cleanUrls, trailingSlash: false
    • Cache-Control: no-store on API routes
    • X-Content-Type-Options: nosniff, X-Frame-Options: DENY on API routes
    • X-Robots-Tag: noindex on source map files
    • maxDuration: 10 on API functions

  For Netlify → netlify.toml or _headers:
    • Similar cache and security headers on /api/* or /.netlify/functions/*

  For Cloudflare → _headers file or wrangler.toml:
    • Similar headers, plus consider enabling Bot Fight Mode if available

  For Express / traditional server → helmet middleware or manual headers:
    • Set the same security headers programmatically

  For Nginx/Apache → server config:
    • rate_limit zone, deny rules, security headers in location blocks

  Always:
    • Disable source maps in production (or restrict access)
    • Set function/request timeouts as low as reasonable
    • Prevent CDN caching of API responses

VERIFICATION
After implementing all 4 layers:
  1. Build the project — confirm it compiles with no errors.
  2. Verify the interceptor/middleware is registered and active.
  3. Verify API routes are dynamic (not statically cached).
  4. Explain what each layer blocks and what it does NOT block.

What Each Layer Stops — And What It Doesn't

Understanding the coverage of each layer helps you assess your remaining risk:

What this system does NOT block:

• Legitimate search crawlers — Googlebot, Bingbot, and similar crawlers are intentionally allowed through. Your SEO is unaffected.
• Real human users — the honeypot is invisible, the rate limiter is generous (30 requests/minute), and origin checks only apply to API routes.
• Sophisticated attackers using real browsers with valid behavior patterns — for that, you need Cloudflare Bot Management, hCaptcha, or Cloudflare Turnstile. This system is deterrence, not a fortress.

Why My First Implementation Failed — And How I Caught It

After running the prompt on my two production sites, I deployed and assumed everything was working. I was wrong.

When I actually tested the live sites, I discovered that the AI agent had only implemented Layer 4 (security headers and vercel.json configuration). It completely skipped creating the middleware.js file (Layer 1), didn't add honeypot fields (Layer 3), and didn't harden any API routes (Layer 2).

How did I find out? I ran the verification tests I'm about to share with you. Every single bot User-Agent returned 200 OK. No middleware existed. The sites were just as exposed as before.

This taught me two critical lessons:

1. Always verify. Don't trust that the AI agent did everything you asked. Run the tests.
2. The prompt needs to be exhaustive. The version above is the refined result — it explicitly names the file to create (middleware.js), specifies the exact checks, and maps each framework to its native mechanism.

The Verification Tests: 8 Ways to Check If Your Site Is Actually Protected

These tests work on your own sites and on any site on the internet. You need curl (pre-installed on Windows 10+, macOS, and Linux) or PowerShell.

Test 1 — Bot User-Agent Blocking

Does the site block requests from known bots based on their User-Agent string?

TARGET="https://your-site.com"

# These should be BLOCKED (expect 403 or 404):
curl -s -L -o /dev/null -w "python-requests → %{http_code}\n" -A "python-requests/2.28.0" "$TARGET"
curl -s -L -o /dev/null -w "curl-bot       → %{http_code}\n" -A "curl/7.88.1" "$TARGET"
curl -s -L -o /dev/null -w "scrapy         → %{http_code}\n" -A "Scrapy/2.11" "$TARGET"
curl -s -L -o /dev/null -w "headless-chrome → %{http_code}\n" -A "HeadlessChrome/120.0" "$TARGET"
curl -s -L -o /dev/null -w "puppeteer      → %{http_code}\n" -A "puppeteer" "$TARGET"
curl -s -L -o /dev/null -w "selenium       → %{http_code}\n" -A "selenium" "$TARGET"
curl -s -L -o /dev/null -w "postman        → %{http_code}\n" -A "PostmanRuntime/7.36" "$TARGET"

# This should be ALLOWED (expect 200):
curl -s -L -o /dev/null -w "real-browser   → %{http_code}\n" \
  -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/125.0.0.0 Safari/537.36" "$TARGET"

# Search crawlers should also be ALLOWED (expect 200):
curl -s -L -o /dev/null -w "googlebot      → %{http_code}\n" \
  -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$TARGET"

Reading the results: Bot UAs returning 403 or 404 = protected. Bot UAs returning 200 = not protected. Real browser and Googlebot should always return 200.

Test 2 — API Origin Enforcement

Does the API reject requests from external origins?

API="https://your-site.com/api/your-endpoint"

# No Origin header — should return 403:
curl -s -w "\nno-origin → %{http_code}\n" \
  -X POST -H "Content-Type: application/json" -d '{"test":"data"}' "$API"

# Wrong Origin — should return 403:
curl -s -w "\nwrong-origin → %{http_code}\n" \
  -X POST -H "Content-Type: application/json" \
  -H "Origin: https://evil-attacker.com" -d '{"test":"data"}' "$API"

# Correct Origin — should return 200 or 400:
curl -s -w "\ncorrect-origin → %{http_code}\n" \
  -X POST -H "Content-Type: application/json" \
  -H "Origin: https://your-site.com" -d '{"test":"data"}' "$API"

Test 3 — Rate Limiting

Does the API limit how many requests a single IP can make?

API="https://your-site.com/api/your-endpoint"

for i in $(seq 1 35); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST -H "Content-Type: application/json" \
    -H "Origin: https://your-site.com" -d '{"test":"data"}' "$API")
  echo "Request $i → $STATUS"
  [ "$STATUS" = "429" ] && echo "✅ Rate limit activated at request $i" && break
done

If 429 appears before request 35, the rate limiter is working. If all 35 return 200, there's no rate limiting.

Test 4 — Content-Type and Payload Guards

Does the API reject wrong content types and oversized payloads?

API="https://your-site.com/api/your-endpoint"
ORIGIN="https://your-site.com"

# Wrong Content-Type — expect 415:
curl -s -w "\nwrong-type → %{http_code}\n" \
  -X POST -H "Content-Type: text/plain" -H "Origin: $ORIGIN" -d "hello" "$API"

# Malformed JSON — expect 400:
curl -s -w "\nbad-json → %{http_code}\n" \
  -X POST -H "Content-Type: application/json" -H "Origin: $ORIGIN" \
  -d "{not valid json" "$API"

Test 5 — Security Headers

Does the server send proper security headers?

curl -s -I -L "https://your-site.com/" | grep -iE \
  "x-content-type|x-frame|strict-transport|content-security|referrer-policy|permissions-policy"

You should see at minimum:

• Strict-Transport-Security: max-age=63072000
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Content-Security-Policy: ...
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: camera=(), microphone=()...

Test 6 — Honeypot Detection

Open the site in Chrome, press F12, go to the Elements tab, and run this in the Console:

document.querySelectorAll('input').forEach(input => {
  const style = getComputedStyle(input);
  const isHidden = style.opacity === '0' || style.display === 'none'
    || style.visibility === 'hidden' || parseInt(style.height) === 0;
  const isSuspicious = ['website','url','fax','phone2','company','address2']
    .includes(input.name);
  if (isHidden || isSuspicious) {
    console.log(`🍯 Honeypot: name="${input.name}" type="${input.type}" hidden=${isHidden}`);
  }
});

If nothing prints, there's no honeypot.

Test 7 — API Cache Control

curl -s -I -L "https://your-site.com/api/your-endpoint" | grep -i "cache-control"

Should return Cache-Control: no-store, no-cache, must-revalidate.

Test 8 — Source Map Exposure

curl -s -I -L "https://your-site.com/_next/static/chunks/main.js.map" \
  | grep -iE "status|x-robots-tag"

Should return 404 (disabled) or X-Robots-Tag: noindex (hidden from search engines).

The Full Verification Checklist

After running all 8 tests, use this checklist to assess your protection status:

If any row fails, the corresponding layer was not properly implemented. Re-run the prompt or fix the specific gap manually.

Real-World Results: Before and After

Here's what my actual audit looked like before the fix:

                        vocab.top    promptbuilder.space
                        ─────────    ───────────────────
Layer 1: Bot Blocking      ❌              ❌
Layer 1: Origin Check      ❌              ❌
Layer 1: Rate Limiting     ❌              ❌
Layer 2: API Hardening     ❌              ❌
Layer 3: Honeypot          ❌              ❌
Layer 4: Security Headers  ✅ (partial)    ✅ (excellent)
Layer 4: Deployment Config ❌              ✅ (partial)

The AI agent had only done the easy part — security headers — and skipped the three most critical layers. After re-running the refined prompt (the one in this article), all 17 checklist items passed.

Adapting This to Your Stack

The prompt is designed to be framework-agnostic. Here's how the AI agent maps Layer 1 (the middleware) to different stacks:

The AI agent picks the right approach based on what it finds in your project. You don't need to specify the framework yourself.

Limitations and Next Steps

This system is deterrence, not an impenetrable fortress. It stops the vast majority of automated abuse — script kiddies, basic scrapers, bot networks using known tools. Here's what it doesn't cover:

• Sophisticated attackers using real browsers with human-like behavior — for this, you need behavioral analysis or CAPTCHA systems like Cloudflare Turnstile or hCaptcha.
• Distributed attacks from thousands of IPs — the per-IP rate limiter won't help if the attacker has a botnet. You need network-level protection from Cloudflare, AWS Shield, or similar services.
• Zero-day exploits in your application logic — this system hardens the transport layer, not your business logic. You still need proper authentication, authorization, and input validation in your core code.

For most independent developers and small teams, this 4-layer system eliminates 90%+ of automated abuse with zero ongoing maintenance cost.

Final Thoughts

The most surprising thing I learned from this project isn't about security — it's about AI coding agents. They are powerful tools, but they are not autonomous security experts. They will do exactly what you tell them to do, skip what you don't mention, and never volunteer that they missed something.

The prompt in this article is the result of multiple iterations, real-world failures, and actual production testing. It works because it's explicit about every file to create, every check to implement, and every edge case to handle.

Copy it. Use it. Test it. And please — always verify.

Disclaimer: The testing methods described in this article are intended for use on websites you own or have explicit permission to test. Running automated security tests against third-party websites without permission may violate their terms of service and potentially applicable laws. Use responsibly.

If you found this useful, follow me for more on web security, AI-assisted development, and building production-grade applications. You can try Prompt Builder at promptbuilder.space and Vocab Top at vocab.top.

Jaber Said

Tags: #WebSecurity #BotProtection #AIAgent #PromptEngineering #WebDevelopment #NextJS #Vercel #APISecurity #RateLimiting #Middleware #DevOps #Cybersecurity