Forge

Security Whitepaper

Enterprise Security Architecture

When you use Forge as your headless form backend, you are trusting us with PII, confidential business data, and in some cases sensitive employee or medical information. This document describes how we protect it.

1. Infrastructure Architecture

Forge operates on a multi-tenant cloud architecture on Amazon Web Services (AWS). Primary infrastructure is hosted in us-east-1. EU customers on the Secure plan can opt into exclusive eu-west-1 data residency, ensuring all data stays within the European Union.

All stateful services run with N+1 redundancy. We do zero-downtime blue/green deployments — there is no scheduled maintenance window. PostgreSQL databases are managed by Supabase with automated daily backups and 30-day point-in-time recovery. Dedicated single-tenant database clusters are available on the Secure plan for enterprise isolation requirements.

2. Encryption Standards

  • In Transit: All API communications use TLS 1.3. TLS 1.0 and 1.1 are permanently disabled. HSTS headers enforce HTTPS with a max-age of 31,536,000 seconds and includeSubDomains.
  • At Rest: All form submissions, file attachments, and credentials are encrypted using AES-256-GCM. Key management uses AWS KMS with automatic annual rotation.
  • Field-level Encryption: Sensitive fields (SSN, bank routing, government ID) can be field-encrypted on the Secure plan using Customer-Managed Encryption Keys (CMEK).

3. Data Isolation & Access Control

All workspaces are logically isolated using row-level security (RLS) enforced at the Postgres layer. Every query is automatically scoped by workspace_id — cross-tenant data access is impossible without a database-layer bypass, which would require compromising the Supabase infrastructure itself.

Dashboard access uses role-based access control: Viewer (read-only), Editor (form management), Admin (team management), and Owner (billing + security). API keys are bcrypt-hashed at rest and are never stored. We cannot recover a lost API key — only rotate it.

4. Webhook Security: HMAC-SHA256 Signing

Every outbound webhook payload is signed with HMAC-SHA256 using your workspace's unique signing secret. The signature is included in the X-Forge-Signature request header. You must verify this signature before processing any payload. We recommend crypto.timingSafeEqual to prevent timing attacks:

import crypto from "crypto";

function verifyForgeSignature(
  rawBody: string,
  signature: string,
  secret: string
): boolean {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody, "utf8")
    .digest("hex");

  return crypto.timingSafeEqual(
    Buffer.from(signature, "hex"),
    Buffer.from(expected, "hex")
  );
}

// In your Next.js Route Handler:
export async function POST(req: Request) {
  const body = await req.text(); // Must be raw string
  const sig = req.headers.get("x-forge-signature") ?? "";
  if (!verifyForgeSignature(body, sig, process.env.FORGE_WEBHOOK_SECRET!)) {
    return new Response("Unauthorized", { status: 401 });
  }
  // Safe to process
  const data = JSON.parse(body);
}

5. Idempotency & Replay Protection

Every webhook includes a unique X-Forge-Event-ID header. Store processed event IDs in Redis with a 24-hour TTL. Before processing any event, check if the ID already exists — this prevents replay attacks from legitimate retries being processed twice.

The submission API itself is idempotent via an Idempotency-Key header. Duplicate submissions with the same key (from clients retrying on network failures) are de-duplicated at the API layer and return the original submission ID without creating a new record.

6. Vulnerability Management

  • Quarterly penetration testing by Cobalt.io (a third-party security firm). Reports available to Enterprise customers under NDA.
  • Automated SAST scanning via Semgrep on every pull request. No critical or high-severity findings are merged without remediation.
  • Dependabot alerts on all repositories. Critical CVEs are patched within 24 hours; high within 72 hours.
  • Engineer on-call rotation 24/7 for P0 security events. On-call contact: security@useforge.cloud.

7. Audit Logging

An immutable workspace audit log captures every significant event: API key creation, rotation, and deletion; form publish and archive; submission export operations; team member changes; webhook configuration; and CORS origin updates. Logs include actor identity, timestamp, IP address, and the specific change made.

Retention: 30 days on Start (free), 12 months on Standard through Max, unlimited on Secure. Audit logs are exportable via API as JSON or CSV for SIEM ingestion.

8. SOC 2 Type II Roadmap

We are actively pursuing SOC 2 Type II certification. Our audit partner is A-LIGN. The observation period begins Q2 2027, with target certification by Q3 2027. Current SOC 2-readiness evidence is available to enterprise customers under NDA on request.

9. Responsible Disclosure Program

If you believe you have found a security vulnerability in Forge, please report it to security@useforge.cloud. Do not disclose publicly until we have had 90 days to investigate and remediate. We commit to:

  • Acknowledging your report within 24 hours
  • Providing weekly status updates throughout investigation
  • Crediting you in our security changelog (unless you prefer anonymity)
  • A monetary bounty for critical vulnerabilities (amount determined by severity and impact)

Last updated: March 2027. For compliance documentation and DPA requests, contact legal@useforge.cloud. See also: Trust Center