Last updated: April 18, 2026

Security Trust Center

Security at FormGen

At FormGen, security is foundational to everything we build. Our customers trust us with their form data, and we take that responsibility seriously. This page provides a transparent overview of the security practices, infrastructure, and policies we have in place to protect your data.

We continuously evaluate and improve our security posture as the platform grows. If you have questions about any of the practices described here, please reach out to our security team at [email protected].

Infrastructure and Hosting

FormGen is hosted on Vercel, which is SOC 2 Type II certified. Vercel provides automatic HTTPS/TLS for all connections, built-in DDoS protection, and a global CDN that ensures fast, reliable access to the platform from anywhere in the world.

All traffic between users and our servers is encrypted in transit. Our infrastructure is designed for high availability with automatic failover and redundancy across multiple regions.

Data Encryption

We apply encryption at every layer of the stack:

• In transit: All data is encrypted using TLS 1.2 or higher. This applies to browser-to-server traffic, server-to-database connections, and all third-party API communication.
• At rest: Application data stored in Neon PostgreSQL is encrypted using AES-256. File uploads stored in Cloudflare R2 use server-side encryption.
• Passwords: User passwords are hashed using bcrypt with a cost factor of 12. Passwords are never stored in plain text and cannot be recovered or decrypted.

Access Controls

FormGen enforces strict tenant isolation at the database level. Every database query that touches user data includes a user or workspace filter, enforced through Prisma middleware. This ensures that users can only access their own data.

Authentication is handled through JWT-based sessions. Users must verify their email address before gaining full access to the platform. We also support OAuth authentication through Google and GitHub for users who prefer delegated authentication.

Application Security

Our application is built with multiple layers of defense:

• Input validation: All user input is validated twice using shared Zod schemas — once on the client for immediate feedback, and again on the server to prevent tampering.
• Parameterized queries: We use Prisma ORM exclusively for database access. No raw SQL is ever executed, eliminating SQL injection as a vector.
• Rate limiting: All endpoints are rate-limited through Upstash Redis. Authenticated users are limited to 100 requests per minute, anonymous users to 20, form submissions to 20 per minute per IP per form, login attempts to 5 per minute, and password-verification attempts to 5 per minute per IP per form. Login, registration, and password-verification endpointsfail closed (return 429) during a Redis outage to prevent credential stuffing when the distributed counter is unavailable. Client IP is derived from the last trusted hop inx-forwarded-forso a spoofed first entry can't bypass a bucket.
• Bot detection: Public form submissions are protected by honeypot fields and timing-based detection to identify and silently reject automated submissions.
• Security headers: We enforce a strict Content Security Policy (CSP) with an allowlist for only the third-party origins we actually use (Stripe, Google Tag Manager / Analytics / Ads, Vercel telemetry). CSP violations are reported to an internal endpoint so we can spot regressions. We also enforce HSTS (withincludeSubDomains and preload), X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, and object-src/worker-src restrictions.
• CORS: Cookie-authenticated API requests only accept the application origin. Bearer-token (mobile) requests are accepted cross-origin but never receiveAccess-Control-Allow-Credentials, so a hostile third-party page can't trick a browser into attaching the victim's session cookie to a forged request.
• Formula injection: CSV exports of form responses neutralize spreadsheet formulas (leading =, +, -, @, |) so a respondent can't plant an =IMPORTXML payload that runs when the form owner opens the file in Excel or Google Sheets.

File Upload Security

File uploads submitted through form fields are protected with multiple layers of security:

• Server-side MIME validation: All uploaded files are validated on the server against an allowlist. SVG is explicitly excluded (it can embed executable JavaScript).
• Server-derived file extensions: The extension used in the stored object key is derived from the server-validated MIME type — never from the client-supplied filename. This prevents path-traversal, null-byte, and double-extension tricks (e.g. receipt.pdf.exe) from ending up in a shareable URL.
• Content-Disposition hardening: Files are served through our own proxy (/api/uploads/serve/) with X-Content-Type-Options: nosniff. Images render inline; everything else (PDFs, Office docs, archives) is served with Content-Disposition: attachmentso it's downloaded rather than rendered in-browser.
• Size limits: File size is enforced per plan tier (10MB for Starter, 50MB for Pro). Theme images (logo and background) are limited to 5MB regardless of plan.

Webhook Security

Webhook integrations are secured through the following measures:

• HMAC-SHA256 signatures: Every webhook payload is signed with a secret key generated using randomBytes(32). Receiving endpoints can verify the signature to confirm payload authenticity and integrity.
• SSRF protection: Destination URLs are validated against an exhaustive list of private / reserved / loopback / multicast / link-local / CGNAT / IPv4-mapped IPv6 ranges using the ipaddr.js library, including numeric IPv4 literal encodings (decimal, hex) that bypass prefix-based checks. DNS is resolved once and the TCP connection is pinned to the validated IP via an undiciagent override, so a malicious authoritative nameserver can't answer with a public IP for the probe and a private IP for the actual request (DNS rebinding). Redirects are treated as delivery failures — the server refuses to follow a 3xx response, preventing redirect-based pivots to internal resources.
• Timeout and retries: Webhook delivery enforces a 5-second timeout per request. Failed deliveries are retried up to 3 times with exponential backoff.

Team Access Controls

Workspace collaboration is governed by role-based access controls:

• Roles: Three roles are supported — owner, admin, and member — each with distinct permission levels. Only owners and admins can invite or remove team members.
• Invitation security:Invitations are issued as UUID tokens sent to the invitee's email address. Tokens expire after 7 days and are single-use.
• Membership limits: Pro plan workspaces support up to 5 team members, enforced at the API level.

Password Protection

Form owners can restrict access to their forms with password protection:

• Password hashing: Form passwords are hashed using bcrypt with a cost factor of 12, the same standard applied to user account passwords.
• Signed cookies bound to the current password: Upon successful password verification, a signed HttpOnly cookie (fp_{formId}) is set with HMAC-SHA256 to prevent tampering. The cookie embeds a 16-character fingerprint of the current bcrypt hash, so rotating the form password instantly invalidates every previously-issued cookie. The cookie uses Secure and SameSite=lax attributes, is scoped to the form path (/f/{slug}), and expires after 24 hours.
• Rate limiting: Password verification attempts are rate-limited to 5 per minute per IP per form to prevent brute-force attacks, and fail closed during a Redis outage.
• Domain-separated signing keys: The HMAC key for the password cookie is derived from AUTH_SECRETvia HKDF-SHA256 with a cookie-specific label. This key is distinct from the mobile JWT, resume-token, and NextAuth session keys — compromising one signing context doesn't affect the others, and the master secret can be rotated safely.

AI Analytics Safeguards

The AI Analytics feature (Pro plan) sends form response data to OpenAI for processing. The following safeguards are in place:

• Opt-in only: AI analytics is never activated automatically. The form owner must explicitly initiate each analysis request.
• Structured output schema: AI responses are constrained to a defined output schema (summary, themes, per-field insights, recommendations) to limit the scope of data returned.
• Volume limits: Each analysis is limited to a maximum of 100 responses to control the amount of data transmitted.

Custom Domain Security

Custom domain integrations are verified and re-verified daily:

• DNS TXT verification: Domain ownership is validated by requiring a specific DNS TXT record at _formgen-verify.{domain}. Forms are not served on a custom domain until verification passes. Each workspace gets a high-entropy (128-bit) verification token that rotates every time the domain is re-set.
• Daily re-verification: A scheduled job re-queries the TXT record for every verified workspace once per day. If the record is gone (domain expired, DNS re-pointed, ownership transferred), the workspace is automatically flipped back to unverified and traffic stops routing to it.
• Blocked suffixes: We refuse custom-domain claims for our own production domain, Vercel preview hosts, IP-rebinding services (nip.io, sslip.io, xip.io), localhost, and IP literals in any form (dotted, decimal, hex, IPv6).
• Transactional claim:The uniqueness check and database write happen inside a single transaction that surfaces the Postgres unique-constraint error as a clean conflict response, so two workspaces can't race to claim the same domain.
• Proxy isolation: Custom domain requests are proxied through our infrastructure with tenant-level isolation and the verification flag is re-checked on every request.

Session and Token Management

FormGen issues several types of signed credentials. Every one of them uses a purpose-specific signing key derived from AUTH_SECRETvia HKDF-SHA256, so compromising one signing context (e.g., a leaked HMAC over an attacker-controlled string in one system) doesn't reveal valid signatures in another.

• Web session (NextAuth JWT): Stored in an HttpOnly cookie, domain-scoped to the application origin. Email verification is enforced at every protected endpoint.
• Mobile app JWT: 30-day bearer token bound to a per-user tokenVersioncounter. Users can invalidate every outstanding mobile token from the web app ("sign out of all devices"), which increments the counter — subsequent token refreshes fail until the user signs in again. Refresh endpoints also always re-check the current email verification and subscription plan from the database.
• Password-gate cookie: HMAC-SHA256 signed, bound to the current bcrypt password hash fingerprint, 24-hour TTL, path-scoped to the specific form.
• Resume tokens: 7-day HMAC-SHA256 URLs that let respondents pick up a draft where they left off. Each token is single-use— once consumed, the same URL can't be replayed (replay returns a "link already used" page rather than exposing the draft again).
• Master-secret rotation: If we ever need to rotate the master signing secret, the platform supports an accept-both window via an AUTH_SECRET_PREVIOUS configuration — in-flight tokens keep verifying during the transition instead of forcing every user to sign out simultaneously.

Audit Logging

All destructive operations are recorded in our audit log. This includes form deletions, response deletions, account changes, and other sensitive actions. Each audit log entry captures the action performed, the user who performed it, the affected resource, a timestamp, and relevant metadata.

Stripe webhook events are also logged to maintain a complete record of payment-related activity. Audit logs are retained and available for review to support incident investigation and compliance requirements.

Data Processing and Privacy

FormGen acts as a data processor when handling form response data. Our customers (form creators) are the data controllers and determine what data is collected from their respondents and how it is used.

A Data Processing Agreement (DPA) is available at /dpa for customers who require one. We do not use tracking or advertising cookies. Data is retained only while your account is active, plus 30 days after account deletion to allow for recovery. For more details, see our Privacy Policy.

Subprocessors

The following third-party services process data on our behalf:

Responsible Disclosure

If you discover a security vulnerability in FormGen, we ask that you report it responsibly by emailing [email protected]. Please include a detailed description of the vulnerability, steps to reproduce it, and any relevant supporting materials.

We commit to acknowledging your report within 48 hours and providing a status update within 5 business days. We do not operate a formal bug bounty program at this time. We ask that you do not publicly disclose the vulnerability before we have had an opportunity to investigate and resolve it.

Incident Response

We classify security incidents by severity: critical, high, medium, and low. Our incident response process includes immediate containment, investigation, and remediation steps proportional to the severity.

In the event of a data breach, we will notify affected users and relevant authorities within 72 hours as required by GDPR. Every incident is followed by a post-incident analysis to identify root causes and implement preventive measures.

Compliance

• GDPR-ready: We offer a Data Processing Agreement (DPA), support data subject rights (access, export, deletion, correction), and commit to 72-hour breach notification.
• CCPA-ready: We support data access, deletion, and portability rights for California residents.
• SOC 2: FormGen is not yet SOC 2 certified. However, our infrastructure providers (Vercel and Neon) are SOC 2 Type II certified. We are actively working toward our own SOC 2 certification.

Contact

For security concerns, contact us at [email protected]. For privacy inquiries, reach out to [email protected]. For general questions, email [email protected].