Security
Forge is architected with a defense-in-depth philosophy. This guide outlines the security mechanisms available to developers and the best practices for integrating Forge into a secure infrastructure stack.
Security Model
Our platform strictly separates concerns between ingestion, storage, and delivery layers. This isolation ensures that vulnerabilities in the ingestion layer (e.g., malformed payloads) do not compromise the delivery infrastructure or data persistence layer.
- Ingestion Layer: Public-facing, ephemeral, and strictly rate-limited. Sanitizes input before it reaches internal systems.
- Platform Layer: Isolated from the public internet. Access is restricted to authenticated internal services.
- Delivery Layer: Outbound-only. Responsible for signing payloads and dispatching webhooks to customer endpoints.
Webhook Security
Securing the receiving end of a webhook is the customer's responsibility. We provide cryptographic proofs to verify that requests originated from Forge and have not been tampered with.
HMAC Signatures
Every webhook request includes an X-Forge-Signature header. This signature is a SHA-256 HMAC of the request body, signed using your unique webhook secret.
Critical Implementation Detail: Verification must occur on the raw request body. Parsing the JSON body before verification (e.g., using `body-parser` in Express) will change the spacing or key order, causing the signature check to fail.
Secret Rotation
If a webhook secret is compromised, you can rotate it immediately via the Dashboard or API. Old secrets remain valid for a configurable grace period (default: 24 hours) to allow for zero-downtime rotation.
Embed Security
When embedding Forge forms directly into client-side applications, you are exposing the endpoint to the public.
Content Security Policy (CSP)
If you use our hosted form scripts, add https://js.forge.devto your script-src directive.
Trusted Origins
Configure "Allowed Domains" in the dashboard. Submissions from unauthorized `Origin` or `Referer` headers will be rejected with a 403 status.
Rate Limiting & Abuse
We apply token-bucket rate limiting to protect platform stability and prevent spam attacks against your infrastructure.
- 429 Too Many RequestsReturned when a form exceeds its per-minute submission quota (default: 60/min).
- 413 Payload Too LargeReturned for bodies exceeding the 4MB limit.
Data Access & Permissions
Environment Separation: Forge enforces logical separation between Development, Staging, and Production environments. Data cannot be moved between environments.
API Tokens: Use restricted API tokens for CI/CD pipelines. Do not use your personal user token for automated services. Tokens usually start with sk_live_... or sk_test_....
Secure Deployment Checklist
Ensure your webhook receiver rejects any request with an invalid HMAC signature.
Return 200 OK immediately. Do not perform long-running tasks (like email sending) within the webhook response cycle.
Log `submission_id` to handle potential retries gracefully without duplicating side effects.
Set up alerts for the Dead Letter Queue to catch persistent delivery failures.