NIZU Shield — Invisible, Self-Hosted Bot Protection

Category: Security & Access Management Applies to: All public-facing forms Availability: All workspaces — no setup required

Overview

NIZU Shield is a built-in, invisible bot protection system that secures every public form in your workspace — without third-party services, external API calls, tracking scripts, or API keys.

Unlike reCAPTCHA, nothing is sent to an outside provider. No cookies are set, no visitor data leaves your server, and your users never see a checkbox, a puzzle, or a "select all the traffic lights" challenge. Protection runs silently in the background while the visitor fills in the form.

This makes NIZU Shield a strong fit for organizations with strict data-protection requirements (GDPR, internal privacy policies, EU data-residency expectations), and for anyone who simply wants forms that work — everywhere, instantly, with zero configuration.

Protected forms

NIZU Shield covers all seven public forms out of the box:

1. Sign up
2. Sign in
3. Password reset
4. Lead collection
5. External support tickets
6. Estimate requests
7. Store orders

All six validating controllers enforce the same checks server-side, so coverage is consistent across the entire platform with no per-form configuration.

How it works

NIZU Shield combines three independent layers. Every layer is validated server-side — a bot must defeat all three to get a submission through.

Layer 1 — Proof-of-work (browser challenge)

When a protected form is rendered, the visitor's browser receives a small cryptographic puzzle: it must find a nonce such that:

SHA-256(salt + nonce)  →  begins with four leading zeros

Solving this requires roughly 65,000 hash attempts, which a modern browser completes in about one second using the native Web Crypto API — silently, while the visitor is still typing. The visitor notices nothing.

What this proves is simple but powerful: a real JavaScript engine actually rendered the page. The overwhelming majority of form-spam bots never load or execute the page at all — they scrape the form once and then POST directly to the endpoint, thousands of times. Without a valid proof-of-work solution, every one of those submissions is rejected before it touches your data.

For a legitimate visitor the cost is one second of invisible background computation. For a spammer trying to submit at scale, the cost multiplies with every single attempt — turning cheap bulk spam into an expensive operation.

Layer 2 — Honeypot field

Each form contains a decoy field named email_repeat that is visually hidden from human visitors. People never see it, so they never fill it.

Bots, however, parse the raw HTML and auto-fill every field they find — including the trap. Any submission that arrives with the honeypot populated is rejected immediately.

Layer 3 — Time trap and replay protection

Every challenge issued by the server is HMAC-signed with a per-workspace secret and carries the timestamp of when the form was rendered. The secret is generated automatically into your workspace settings the first time a protected form is rendered — there is nothing to create, copy, or configure.

On submission, the server rejects any request that is:

Because the signature is bound to your workspace's own secret, a challenge harvested from one workspace is useless against any other.

Why three layers

Each layer targets a different class of bot:

• Direct-POST bots (the vast majority of form spam) never execute JavaScript — stopped by the proof-of-work.
• Naive headless bots that do render the page typically auto-fill every input — stopped by the honeypot.
• Sophisticated bots that render the page and skip hidden fields still can't submit instantly, hoard challenges, or replay a solved one — stopped by the time trap and replay block.

A failure in any single layer doesn't compromise protection, and all decisions are made server-side, where a bot can't interfere.

How it's wired in

NIZU Shield is implemented as a third verification protocol alongside the existing reCAPTCHA v2 and reCAPTCHA v3 options. It plugs into the same validation pipeline, which means:

• All seven public forms gained protection with no per-form changes.
• All six validating controllers enforce it through the existing verification flow.
• Switching between NIZU Shield, reCAPTCHA v2, and reCAPTCHA v3 is a single setting — no code changes, no redeployment.

Choosing a protocol

If your workspace currently uses reCAPTCHA and you want to remove the external dependency, switch the protocol to NIZU Shield in Settings → Security. Existing forms pick up the change immediately.