htmlcontact
Sign in Sign up
Legal

Security

Security

How html.contact protects accounts, submissions, attachments, API keys, and form endpoints.

Last updated: October 2, 2026

html.contact is built on Cloudflare Workers, D1, R2, and Cloudflare Email. This page explains the security controls we use today and the limits of what we claim at launch.

Infrastructure And Encryption

Data is encrypted in transit and encrypted at rest by our infrastructure providers. Dashboard and API access are protected by authenticated sessions or scoped API keys, and customer records are accessed through tenant-scoped authorization checks.

API keys, linked-email and recipient verification links, and Agency invitations are stored as keyed hashes. Zapier connection tokens and authorization codes are stored as hashes.

html.contact’s own rate limits and abuse controls, including those on form submissions, use keyed hashes of IP addresses. Rate limits on sign-in, sign-up, password-reset, and other account requests are kept by our authentication library, which records the requester’s raw IP address together with the request path; see the Privacy Policy. Submission records also keep the visitor’s raw IP address and Cloudflare request metadata for abuse and security review; see the Privacy Policy.

Sign-in sessions and password-reset links are managed by our authentication library, which stores their tokens without hashing. Password-reset links expire after one hour.

Form submission content is stored so customers can view, export, and manage submissions; html.contact does not currently offer customer-managed keys or field-level encryption for submission contents.

Account And API Access

  • Dashboard access uses authenticated account sessions.
  • Agency API access uses account-owned hc_live_ API keys, either Full (every capability across the whole account) or Restricted to selected capabilities on selected client workspaces or the whole account.
  • A private API key’s full value is returned only when the key is created.
  • Private API keys are stored as keyed hashes.
  • Public hc_pub_ keys can submit to one form and cannot read submissions, edit forms, manage billing, create API keys, or access accounts.
  • Private hc_live_ keys must never be placed in browser code.
  • Admin access is allowlisted and used for support, abuse, security, and operations.

Public Form Protections

html.contact protects public form endpoints with:

  • Unguessable public form keys.
  • Per-form allowed-domain checks.
  • Source-header checks using Origin and Referer.
  • Recipient verification.
  • Server-side spam screening.
  • Honeypot checks.
  • D1-backed rate limits.
  • Account-level usage limits.
  • Payload, field-count, field-length, attachment-count, and attachment-size limits.
  • Suppression and recipient-health checks.

Origin and Referer are browser-source signals, not cryptographic proof. Dashboard and docs should describe this as “source matched an allowed domain”, not “verified source”.

Attachments

html.contact supports one attachment up to 4 MB per submission at launch.

Attachments are stored privately in R2. Downloads require authenticated dashboard or API access. R2 object keys are not exposed in normal customer-facing responses.

Attachments are user-submitted and untrusted. html.contact does not provide malware scanning at launch. If you were not expecting an attachment, or your form is not intended to accept multipart/form-data, do not open unexpected files. Scan downloads with your own security tools before opening them.

Backups And Restore

Submission metadata stored in D1 has platform-level point-in-time recovery (Cloudflare D1 Time Travel). Every release records a restore point before it applies database migrations, and we follow a written internal restore procedure. A point-in-time restore applies to the whole database, so we repair problems forward where we can. Attachments are stored privately in R2, but html.contact does not currently offer a formal attachment backup/restore SLA.

Customers are responsible for exporting data they need to keep independently.

What We Do Not Claim At Launch

At launch, html.contact does not claim:

  • SOC 2 certification.
  • Formal penetration testing.
  • A formal vulnerability scanning program.
  • Customer-managed keys.
  • Field-level encryption for submission contents.
  • Hashing of sign-in session tokens or password-reset tokens.
  • Hashing of IP addresses in sign-in and account rate-limit records.
  • Malware scanning.
  • A formal disaster recovery SLA.
  • A formal attachment backup/restore SLA.
  • Formal staff training or background-check programs.

Vulnerability Disclosure

We welcome good-faith vulnerability reports. Email security@html.contact with enough detail for us to reproduce the issue.

Do not:

  • Access, modify, delete, or exfiltrate other users’ data.
  • Perform denial-of-service testing.
  • Send spam or phishing.
  • Use social engineering or physical attacks.
  • Run automated high-volume scanning.
  • Publicly disclose a vulnerability before we have had a reasonable chance to investigate.

We do not offer a bug bounty or paid rewards unless agreed in writing before testing.

Our machine-readable security contact is available at /.well-known/security.txt.

Security Contact

Security reports and security questionnaires should go to security@html.contact.