Security | html.contact

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, verification tokens, and operational IP hashes are stored as hashes. 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.
Private API access uses scoped hc_live_ API keys.
Full private API keys are returned only when created.
Private API keys are stored as 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 and internal restore procedures. 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.
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.