FormsFort
EN ES

Security

Production security for form infrastructure.

FormsFort implements encryption, access controls, abuse prevention, attachment scanning, audit logging, and automated release gates. These controls are verified in CI and during every production deployment.

Encryption

  • TLS for all API, dashboard, admin, and website traffic
  • Access keys hashed with a server-side pepper; full keys never exposed in dashboard or support views
  • Email retry payloads, webhook target URLs, webhook retry payloads, Google Sheets retry payloads, captcha secrets, and integration config encrypted at rest
  • OAuth refresh tokens for Google Sheets encrypted in the database, never returned by the API

Access controls

  • Dashboard routes require authenticated sessions
  • Dashboard support requests require authenticated sessions
  • Admin support operations are isolated behind Basic Auth and a server-only admin token
  • Control-plane browser requests allowed only from the configured dashboard origin
  • Cross-site browser mutations to /v1/* and /auth/* blocked by Origin and Fetch Metadata checks
  • Admin app protected by Basic Auth credentials

Data minimization

  • Raw submission bodies are not stored; only field names, hashes, request IDs, statuses, and redacted metadata are retained
  • Successful email and webhook delivery payloads are redacted after delivery
  • Dead-letter and support views expose operational metadata only, not raw payloads
  • Account-deletion completion anonymizes identity data and avoids writing requester PII into the audit log

Abuse and spam prevention

  • Fixed-window rate limits per IP, per form, and per window size
  • Honeypot field rejection for automated bots
  • Spam scoring based on link-heavy content and common spam-term patterns
  • Abuse block and allow rules for IP, browser-origin domain, user agent, submitter email domain, TLD, and repeated message text
  • Captcha providers (reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile) fail closed with bounded verification timeouts
  • Recipient suppression list blocks bounced or unsafe outbound emails before delivery

Attachment scanning

  • Inline multipart attachments scanned before delivery is queued
  • Advanced object-storage uploads require a clean ClamAV scan before a submission can consume the storage key
  • Form-level enforcement of max file count, max file size, allowed MIME types, and blocked executable/script-like filename extensions
  • Submitted storage keys are single-use and atomically consumed

Observability and audit

  • Every API response includes X-Request-Id, X-Trace-Id, and W3C traceparent headers
  • Audit logs record entitlement assignments, profile/security changes, form lifecycle and setting changes, integration changes, workspace member and invitation changes, abuse-rule mutations, suppression changes, account-deletion requests and completions, and admin-triggered integration tests
  • Built-in alert evaluation for queue backlog, delivery failures, HTTP non-2xx volume, submission blocks, rate-limit buckets, blocked attachment scans, upload storage errors, and pending upload reservations
  • Alerts can be routed to external incident webhooks with separate warning, critical, and escalation channels

Browser security headers

  • Content-Security-Policy (CSP)
  • Strict-Transport-Security (HSTS)
  • X-Frame-Options (frame protection)
  • Referrer-Policy
  • X-Content-Type-Options (nosniff)
  • Permissions-Policy

Webhook safety

  • Webhook targets must use HTTPS in production
  • Targets cannot include embedded credentials, point at loopback or private address literals, or resolve to private DNS
  • Outbound attempts bounded by configurable timeouts so slow endpoints fail into the retry/dead-letter path

Release gates

Every production deployment passes through automated release gates. These are enforced in CI and cannot be skipped.

  • CI passes formatting, type checks, tests, Drizzle migration checks, and production builds on every push
  • Production config check fails on unsafe defaults, localhost URLs, private-address public URLs, missing secrets, and insecure launch URLs
  • API and worker processes refuse to start with failing production config when NODE_ENV=production
  • Database migration evidence captured before deployment
  • Restore verification runs against an isolated PostgreSQL database, not the production database
  • Launch evidence checks API, dashboard, and website reachability plus required browser security headers before running a load-test drill
  • Security checklist requires Engineering, Operations, and Security/Privacy sign-off with concrete names and dates
  • Release bundle verifier revalidates all source artifact hashes and database identities before final deployment

Planned improvements

These items are on the roadmap but are not yet completed. FormsFort does not currently hold any third-party security certifications.

  • SOC 2 Type II audit
  • Formal penetration testing by a third-party firm
  • Bug bounty program

Report a vulnerability

If you believe you have found a security vulnerability in FormsFort, report it responsibly to [email protected]. Please include steps to reproduce, affected endpoints, and your assessment of severity. We will acknowledge receipt and provide a timeline for remediation.

Contact security Read the docs