This article explains the protections we have in place (in addition to reCaptcha) to help prevent automated and malicious intake form submissions.
Bot protection and server-side safeguards
reCAPTCHA v2 is verified server-side on every submission for forms with it enabled. A submission without a valid token is rejected and no record is created.
All production traffic is proxied through Cloudflare, which provides DDoS mitigation, a managed Web Application Firewall covering the OWASP Top 10, and IP-reputation threat scoring on every request.
Each request's Cloudflare threat score and classification, client IP, and request ID are captured in our monitoring and logging stack for abuse investigation.
Submissions are bound to a specific organization and form ID. Forms can be disabled at any time by your team, which immediately stops accepting submissions.
iframe security
The form is served from app.eventtemple.com over HTTPS and is designed to be embedded on customer websites, so it is intentionally frameable by third-party origins.
Because the form runs in its own origin, the browser's same-origin policy isolates it from the host page. The host page cannot read form contents, and the form cannot access the host page's DOM, cookies, or storage.
Standard hardening headers are set: X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, X-Permitted-Cross-Domain-Policies none, and HTTP Strict Transport Security.
The form's API calls are same-origin. Cross-origin API access is restricted by CORS to Event Temple's own front-end origins.
Cross-origin messaging
The intake form does not use postMessage or any other cross-origin messaging with the host page in either direction
The only interaction with the parent page is the optional redirect after submission, which navigates to a URL your team configures in Event Temple and which is validated on save.