Prompt for model to add protection for your backend from scanners A developer published a reusable prompt instructing AI coding assistants to implement a four-layer, fail-open backend defense against automated scanners, log exhaustion, and OTP brute-forcing. The blueprint covers verified reverse-proxy IP resolution, a Redis-backed progressive ban engine with stealth 404s and time-capped bans, an exception filter that keeps 4xx errors out of the database, and distributed OTP attempt counters with a five-failure limit. It emphasizes parameterized thresholds, fail-open behavior under Redis latency, and avoiding hardcoded secrets. Purpose: Hand this document to any AI coding assistant or backend engineer to implement a production-grade, fail-open bot scanner defense, reverse proxy IP resolution, log exhaustion prevention, and OTP brute-force protection system in any backend service. You are an expert backend security and infrastructure architect. Your task is to implement a robust, fail-open defense system against automated scanners, web crawlers, log exhaustion attacks, and brute-force credential abuse. Follow the requirements, algorithms, and implementation blueprints defined below. Maintain fail-open availability: security controls must never degrade uptime or block legitimate users if secondary systems like Redis experience latency or outages. Do not hardcode any sensitive credentials, production ports, or environment-specific secrets. Keep all thresholds and configurations parameterized. Do not use emojis in code comments, responses, or commit messages. 1. Automated Vulnerability Scanning: Botnets and scanners Shodan, Censys, automated crawlers bombard endpoints searching for sensitive paths .env , .git , wp-login.php , phpmyadmin , backup dumps . Leaving these unmitigated wastes CPU, memory, and database bandwidth. 2. The "Self-Inflicted Proxy DoS" Trap: When running behind reverse proxies Cloudflare, Nginx, container networks , naively blocking req.ip without configuring proxy trust bans the reverse proxy itself, creating a 100% outage for all users. Reading headers like X-Forwarded-For or CF-Connecting-IP directly without verification allows attackers to spoof arbitrary IP addresses. 3. Database Log Exhaustion 404 Floods : Applications that log unhandled exceptions to a database table suffer catastrophic disk I/O and storage bloat when a scanner generates hundreds or thousands of 404 requests in seconds. 4. Carrier-Grade NAT CGNAT Collateral Damage: Mobile users share public carrier IP addresses. Permanent IP bans will inevitably block innocent users on the same cell tower or public Wi-Fi. Bans must be progressive and strictly time-capped. 5. OTP Credential Brute-Forcing: 6-digit numeric OTPs have 1,000,000 combinations. Without distributed attempt counters, bots can brute-force codes within their active validity window. You must implement four distinct defense layers: Incoming Request │ ▼ Layer 1: Reverse Proxy & Real IP Resolution - Trust only verified proxy CIDRs Cloudflare + Local/Container networks - Framework right-to-left X-Forwarded-For traversal │ ▼ Layer 2: Scanner Detection & Progressive Redis Ban Engine - Whitelist bypass for legitimate application routes /api/v1/ , etc. - Fast regex for scanner probes, dangerous extensions, and malformed URIs - Configurable strike sliding window in Redis e.g. 3 strikes in 60s - Stealth 404 responses during probing do not signal an active WAF - Progressive ban durations with 24h retention e.g. 15m - 30m - 1h max - Generic 403 Forbidden for actively banned IPs no fingerprinting - Strict fail-open design with command timeout <= 80ms │ ▼ Layer 3: Global Exception Filter Log Exhaustion Guard - Never write 4xx errors especially scanner 404s to the database - 404s logged at debug level only - Other 4xx logged at warning level - 5xx logged at error level and persisted to database/persistent storage │ ▼ Layer 4: Distributed OTP Brute-Force Protection - Redis attempt counter scoped to normalized recipient identifier - TTL matching the OTP expiration window - Hard limit of 5 failed attempts - Automatic database revocation of active OTPs upon threshold breach When generating or deploying this system, strictly enforce the following rules: 1. Parameterize Timing & Strike Thresholds: Do not hardcode strike limits e.g., 3 strikes in 60s where an attacker reading source code can calibrate scan speed to fly just under the radar. Allow overriding via environment variables. 2. Prevent Server Fingerprinting: Return generic, standard error messages e.g. standard 403 Forbidden response rather than custom signatures that identify the backend technology or internal firewall software. 3. Strict Whitelist Boundary: Never put root / , wildcard patterns, or public user-content paths into the safe route bypass list. Only include verified application route prefixes. 4. Mandatory Expiration TTL on All Cache Keys: Every key created in Redis scan:strike: , scan:ban: , scan:offenses: , auth:otp attempts: MUST have an explicit TTL. Never write unbounded keys that can lead to memory exhaustion OOM DoS . 5. No Direct Header Trust: Under no circumstances should req.headers 'x-forwarded-for' or req.headers 'cf-connecting-ip' be read directly. Trust proxy configuration must be used so the framework validates proxy hops. 6. No Secret Leaks in Exceptions: Ensure exception filters sanitize query params, request bodies, and database errors to prevent leaking database structure or environment variables in responses. Ensure req.ip resolves to the authentic remote client IP, preventing both proxy banning and header spoofing. 1. Never read req.headers 'x-forwarded-for' or req.headers 'cf-connecting-ip' directly. 2. Configure framework proxy trust using verified upstream CIDR blocks. 3. Express/Connect-based frameworks evaluate X-Forwarded-For from right to left, stripping trusted hops until the first untrusted IP is reached. Include official Cloudflare ranges and private container/bridge networks adjust if your reverse proxy infrastructure differs : - Private / Container Networks: 'loopback' , 'linklocal' , 'uniquelocal' - Cloudflare IPv4: 173.245.48.0/20 , 103.21.244.0/22 , 103.22.200.0/22 , 103.31.4.0/22 , 141.101.64.0/18 , 108.162.192.0/18 , 190.93.240.0/20 , 188.114.96.0/20 , 197.234.240.0/22 , 198.41.128.0/17 , 162.158.0.0/15 , 104.16.0.0/13 , 104.24.0.0/14 , 172.64.0.0/13 , 131.0.72.0/22 - Cloudflare IPv6: 2400:cb00::/32 , 2606:4700::/32 , 2803:f800::/32 , 2405:b500::/32 , 2405:8100::/32 , 2a06:98c0::/29 , 2c0f:f248::/32 Detect automated bot probes, increment strike counts in Redis, ban repeat offenders progressively, and return stealth responses. Before route handling, check if the client IP exists in Redis: - Redis key: scan:ban: