Benefits — CWaptcha

CWaptcha vs the alternatives

Feature	CWaptcha	reCAPTCHA v3	hCaptcha	Turnstile
User interaction required	None	None (score-based)	Puzzle	None
Data sent to third party	None	Google	hCaptcha	Cloudflare
GDPR DPA required	No	Yes	Yes	Yes
Works on private / intranet	Yes	No	No	No
Per-request cost	None	None	Yes (at volume)	Paid tiers
Vendor outage risk	None	Yes	Yes	Yes
Multi-node support	Yes (IDistributedCache)	N/A	N/A	N/A
NuGet package	Yes	No (manual setup)	No	No
Dev hours to integrate	~1 hour	~2–4 hours	~4–8 hours	~2–4 hours

Advantages in depth

🔒 No user friction = more conversions

reCAPTCHA v3 shows a visible badge on every page. Puzzle-based CAPTCHAs frustrate users — studies show up to 29% abandonment when a CAPTCHA challenge appears. CWaptcha is completely silent. Your users never know it's there.

🇪🇺 One-sentence GDPR story

No data leaves your servers. There is nothing to declare to your DPO, nothing to add to your cookie banner, and no Data Processing Agreement to sign with a third party. If your legal team has blocked reCAPTCHA over GDPR, CWaptcha is the answer.

🏗️ Zero vendor dependency

CWaptcha runs entirely inside your infrastructure. No external API calls. No CDN dependency. Works on air-gapped servers, corporate intranets, and development machines with no internet access.

💰 Predictable zero cost

One NuGet package. No API keys, no monthly invoices, no per-request pricing. Deploy to as many environments as you need — development, staging, production — at no additional cost.

🔑 Cryptographically verifiable

Every submission carries an HMAC-SHA256 proof that the form fields were not altered in transit. Constant-time comparisons prevent timing attacks. One-time nonces prevent replay attacks. The same threat model as enterprise solutions.

♿ Accessibility-first

Puzzle CAPTCHAs are notoriously difficult for users with visual impairments, cognitive disabilities, and dyslexia. CWaptcha has no puzzle, no visual challenge, no audio fallback needed — it's fully accessible by nature.

Dos & Don'ts

✓ Do

Use HTTPS in production — Enable RequireHttps: true. CWaptcha's HMAC provides integrity but relies on TLS for confidentiality of the nonce.
Set short TTLs — Keep NonceTtlSeconds ≤ 300 (5 min). Longer TTLs widen the window for replay on other sessions.
Use distributed nonce store on multi-node — Call .UseDistributedNonceStore() behind a load balancer to avoid nonce lookup failures on different nodes.
Keep SecretKey secret — Store via user-secrets, environment variables, or Azure Key Vault. Never commit to source control.
Protect POST handlers, not GET — Only the form submission endpoint needs protection. The page-render GET should be unprotected.

✗ Don't

Don't apply both protection mechanisms to the same route — Using ProtectedPaths middleware AND [CWaptchaValidation] on the same endpoint double-redeems the nonce. The second check always fails.
Don't reuse a nonce across navigations — Each page load fetches a fresh nonce. Navigating back and reusing an old token will always fail.
Don't use MemoryNonceStore behind a load balancer — Without sticky sessions, nonces will be lost when requests are routed to different nodes.
Don't commit SecretKey to appsettings.json — Use dotnet user-secrets in development and environment variables in production.
Don't use CWaptcha as the only security layer — CWaptcha is bot protection, not authentication or authorisation. Combine it with rate limiting and input validation.