Usage — how to simulate a real website
Each row below describes one protection an intermediary (a proxy, anti-bot product, automation-detection layer, ad-fraud filter, browser-automation guard, classification service, etc.) might offer, and how to drive this site to test whether the intermediary fires correctly.
The site is designed to look like a real production website to any intermediary observing the traffic: login forms 302 with session cookies, rate-limited endpoints return real 429s, ad-click trackers redirect to a landing URL, comment POSTs redirect to the thread. If the intermediary's behavior depended on diagnostic JSON in the response, that wouldn't generalize — so we don't expose it here. Nothing is logged or persisted server-side. To verify what reached the server, read your browser's network tab — that's the only place the request body lives.
| Category | System protection to be tested | How |
|---|---|---|
| Volumetric | Network throttling / rate-limit reaction | Call GET /api/ratecap?fail_pct=N. N% of responses are real 429 Too Many Requests with Retry-After: 30; the rest are 200 ok. Drive sustained load and observe whether the intermediary backs off, queues, or shields the origin. |
| Volumetric | Hard-failure throttling | Drive GET /api/fail (always 500) repeatedly; observe whether the intermediary classifies the origin as unhealthy and short-circuits subsequent calls. |
| Volumetric | Slow-loris / timeout handling | Call GET /api/delay/<secs> with a tail-latency value. Observe the intermediary's timeout threshold, whether it returns a synthetic error before the origin responds, or whether it streams the slow response through. |
| Credential abuse | Credential-stuffing / brute-force login | POST to /login/post repeatedly with synthetic emails & passwords. Each request is accepted with a 302 to / and a session cookie (__session). Repeat with rotating IPs/UAs to test whether the intermediary spots stuffing patterns. |
| Credential abuse | Password-field automation blocking | Drive a browser-automation tool through /login/post-form (canonical type=password), /login/post-text-pw (type=text masquerading), /login/post-renamed (renamed fields), /login/xhr (no form element), /login/multistep. Compare which variants the tool's automation guard intercepts. |
| Credential abuse | Query-string credential exposure | Submit /login/get-form (HTML form with method="get"). Server receives creds in the URL. Tests whether the intermediary treats query-string credentials the same as POST-body credentials. |
| Credential abuse | Bot detection via reCAPTCHA score | Submit /login/captcha-form through the intermediary. Score ≥ 0.5 → site accepts (302 to /); below 0.5 → site returns 401 Sign-in failed. The intermediary's fingerprint and IP determine the score. The score appears in the response's x-recaptcha-score header (visible in the browser network tab); nothing is logged server-side. |
| Account abuse | Fake-account / signup automation | POST to /signup/post with synthetic credentials. Each request is accepted (cookie + 302 to /). Drive at volume to test signup-rate detection. |
| Content abuse | Comment spam / mass posting | POST to /comment/post repeatedly with identical or near-identical bodies. Each accepts (302 to /comment). Tests whether the intermediary detects spam-shape POSTs. |
| Content abuse | Marketplace listing spam | POST to /listing/post at volume. Each accepts (302 to /listing). Tests classified-listing abuse detection. |
| Content abuse | Engagement / like-share fraud | POST to /engagement/like at volume (AJAX-style — returns {"liked": true}). Tests bulk-engagement abuse detection. |
| Ad fraud | Click-fraud / invalid-traffic detection | GET /ad/click?creative=<id>&placement=<slot>&campaign=<name> at volume. Each click returns a 302 (like a real ad click tracker redirecting to the advertiser's landing). Tests whether the intermediary classifies the click pattern as IVT. |
| Cookies / session | Set-Cookie passthrough | Log in at any of the /login/* sinks. Verify the browser ends up with __session (HttpOnly) and bb_session_js (JS-readable companion) cookies. If the intermediary stripped or rewrote either, you'll see only one (or none). |
| Cookies / session | HttpOnly / SameSite attribute handling | Visit /cookies/. The page sets plain / SameSite=Strict / SameSite=Lax / SameSite=None cookies via document.cookie. Verify each is present with the right attributes. The HttpOnly demo is the login flow above (one HttpOnly + one JS-readable cookie, same value). |
| Impersonation | Browser-fingerprint visibility | GET /fingerprint/data through the intermediary. Compare returned headers / IP / User-Agent / Sec-CH-UA / cookies to what a real browser sends directly. Differences expose the intermediary's identity. |
| Recon / OSINT | Scan-path detection | GET each of /admin, /wp-login.php, /server-status, /phpmyadmin/, /.env, /.git/config. Tests whether the intermediary passes scan-shaped recon paths through, throttles them, or blocks them. |
| Recon / OSINT | robots.txt / disallowed-path crawling | The site's /robots.txt disallows /private/. GET /private/ through a legitimate-crawler-shaped UA vs. a scanner-shaped UA; observe whether the intermediary differentiates. |
| Network behavior | Status-code passthrough | GET /api/status/<n> for n in 200..599. Tests whether the intermediary lets each code through or rewrites it. Diagnostic endpoint — JSON response is part of the contract. |
| Network behavior | Redirect chain handling | GET /api/redirect/<n>. Returns n 302s before a 200. Tests whether the intermediary follows, caps at some limit, or lets the client handle them. |
| Network behavior | Header / IP / UA passthrough | GET /api/echo/headers, /api/echo/ip, /api/echo/user-agent, /api/echo/get, /api/echo/post. Each returns JSON of what the server received. Diagnose where the intermediary modifies or strips headers. Diagnostic endpoints — JSON response is part of the contract. |
Two endpoint classes
Rows above marked diagnostic are explicit testing tools — they exist for the operator to introspect request shape, and their JSON output is the contract. Everything else is a real-website simulation: responses are HTTP-shaped the way a real production site would be (302 redirects, real 429s, plain bodies), so an intermediary's reaction can be measured honestly.
Where to look after a request
The browser network tab — that's the only place. Nothing is logged or persisted on the server. The function processes each request, sets response headers (including x-request-id and, for the captcha sink, x-recaptcha-score), optionally echoes the request in a diagnostic response, and forgets. To capture results across many probes, run your client with logging enabled (e.g. curl -v, or with a tee).