Security

Access key security

Every form uses a unique access key (prefixed w3f_). The key is shown once when you create a form — after that, we only store a SHA-256 hash. We never store or log the raw key. If you lose your key, delete the form and create a new one.

Your access key will be visible in your HTML source code — this is expected. The key identifies which form to deliver to, but it does not grant access to your dashboard, submissions, or account. Think of it like a mailing address: anyone can send a letter, but only you can open the mailbox.

To prevent unauthorized sites from using your key, always configure Allowed Domains (see below).

Allowed domains

The most important security setting. In Form → Settings → Allowed Domains, list every domain that hosts your form (e.g., yoursite.com, www.yoursite.com). Submissions from any other origin are rejected with a 400 error.

During development, localhost is allowed by default. Before deploying to production, add your production domain. Redirect URLs must also match an allowed domain or use a relative path.

Learn more in Customization.

Spam protection layers

W3Forms offers four layers of spam protection. You can combine them for defense in depth:

• Honeypot field — An invisible input that real users never fill out. If a bot fills it, the submission is flagged as spam. This is zero-friction and works well for most sites. Add a hidden field with style="display:none" and tabindex="-1".
• Keyword blacklist — Comma-separated words or phrases. Any submission containing a blacklisted term is marked as spam. Useful for blocking repeat patterns like "crypto" or "casino."
• Disposable email blocking — Rejects submissions from known throwaway email domains (mailinator.com, guerrillamail.com, etc.). Enable in Form → Settings.
• Captcha — For higher-risk forms, enable captcha in settings and add the widget to your form. This adds friction but blocks automated submissions effectively.

Spam submissions are stored in your dashboard (marked as spam) but do not trigger email notifications or webhooks. Spam does count toward your monthly submission quota.

Webhook signature verification

Every webhook request includes an X-W3Forms-Signature header containing an HMAC-SHA256 signature of the raw request body, computed with your webhook secret. Always verify this signature before processing the payload.

Use constant-time comparison (e.g., crypto.timingSafeEqual in Node.js, hmac.compare_digest in Python) to prevent timing attacks. Never log or expose your webhook secret in client-side code.

See Webhooks for complete verification examples in Node.js and Python.

Data handling

All submission data is stored in encrypted PostgreSQL databases. Connections to the W3Forms API and dashboard use HTTPS/TLS encryption in transit. We do not sell or share your data with third parties.

You can delete individual submissions from your dashboard. When you delete your account, all associated data (forms, submissions, access keys) is permanently removed within 30 days.

For full details, see our Privacy Policy and Terms of Service.

Rate limiting

W3Forms applies rate limits per IP address on the submission endpoint to prevent abuse and denial-of-service attacks. If a single IP exceeds the rate limit, subsequent requests receive a 429 response until the window resets. Rate limits are generous enough for normal form traffic but strict enough to block automated attacks.

Security checklist

• Configure Allowed Domains for every form.
• Enable at least one spam protection layer (honeypot recommended).
• Verify webhook signatures before processing payloads.
• Keep webhook secrets out of client-side code and version control.
• Use HTTPS on your own site to protect form data in transit.
• Review your submissions dashboard regularly for spam patterns.