Security Standards

A small attack surface, on purpose

This site is static HTML served from a CDN, with a single serverless function that relays form submissions to email. There is no database, no user accounts, no logins, and no payment processing on this property — which means entire categories of risk simply don't exist here. We don't store your form submission in a database; it's delivered to us and not retained.

Encryption and security headers

Every page is served over HTTPS, and an HSTS policy tells browsers to refuse insecure connections. A Content-Security-Policy tightly restricts where scripts, styles, and connections may load from — our own origin plus a small, named set of trusted providers — and we set the standard hardening headers so the browser enforces our rules rather than trusting our intentions:

• Strict-Transport-Security (HSTS) with a long max-age
• Content-Security-Policy limiting where scripts, styles, and connections can come from
• X-Frame-Options: DENY and frame-ancestors 'none' (clickjacking protection)
• X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a Permissions-Policy disabling unused device APIs
• Cross-origin isolation (COOP / CORP)

Form and function hardening

The one function that accepts input is written defensively: server-side validation on every field, request size and timeout limits, per-IP rate limiting, a honeypot and spam heuristics, a strict origin allow-list, output encoding, and protection against email header injection. Errors shown to visitors are generic, and submissions are never logged with personal data.

Authenticated email and protected secrets

Our sending domain is protected with SPF, DKIM, and DMARC, so recipients can trust mail from us and spoofed messages are rejected. API keys live only in the host's environment variables — never in the code or its version history — and we keep a written runbook for rolling back a bad deploy and rotating keys.

Built with zero dependencies

The site uses no third-party framework or package dependencies. That removes the single most common source of web vulnerabilities — a compromised or out-of-date dependency — because there's almost no code here we didn't write. Less code we didn't write means less that can quietly go wrong.

Reporting a vulnerability

If you believe you've found a security issue with this site, we want to hear from you. Email info@tobex.io (also published at /.well-known/security.txt) and we'll respond promptly. Security is an ongoing practice for us, reviewed as the site changes — not a one-time checkbox.

This is the standard this site is held to; it's the same care we bring to the sites and systems we build for clients.

The rest of our standards