Security & Responsible Disclosure

1. Our approach

We build against recognized standards — the OWASP Application Security Verification Standard and the OWASP API Security Top 10 — and treat our security posture as code: it is reviewed, tested, and, because the project is open source, auditable by anyone at our repository. We favor fail-closed defaults: when a security-relevant check cannot be satisfied, the Service refuses rather than proceeds.

2. Technical measures

• Encryption in transit across all public endpoints, with HSTS and modern TLS.
• Encryption of sensitive secrets at rest — per-tenant control-plane credentials are sealed with authenticated encryption before storage and never sent to the browser.
• Bring-your-own DNS tokens are not stored — provider access tokens are used once to apply the requested records and then discarded.
• Tenant isolation— access is scoped so cross-tenant probes return "not found" without leaking existence; API keys are stored hashed and verified in constant time.
• SSRF hardening — outbound webhooks validate targets at registration and re-validate at dial time to block private, loopback, and metadata addresses.
• Rate limiting and request-size caps protect against abuse and resource exhaustion.
• Signed webhooks (HMAC over timestamp and body) with replay protection.
• Browser hardening — security headers including a content security policy, clickjacking protections, and a framework fingerprint that is not advertised.
• Hardened runtime — minimal, non-root containers; Postgres is not exposed publicly; production refuses to boot without its required secrets.
• Least-secret logging — request logs record method, path, status, and timing, and are designed to exclude tokens, bodies, and query strings.

This page forms Annex II (technical and organizational measures) to our DPA and is kept current as the Service evolves.

3. Data protection

Encryption keys and application secrets are supplied via the environment and are never committed to source control. Access to production is limited and least-privilege. For how we handle personal data, retention, and your rights, see the Privacy Policy; for our vendors, see the Sub-processors list.

4. Compliance status (honest)

We believe in being straight about where we are:

• Not yet SOC 2 certified. A SOC 2 program is on our roadmap (Type I first, then Type II). See the repository and our compliance roadmap for status.
• Content Security Policy is being tightened.The console's full CSP currently runs in report-only mode while we move to nonce-based enforcement.
• High availability is in progress. We are moving to a multi-instance, managed-database topology; backups are in place today.

We will update this section as milestones land. If you need current documentation for a vendor review, contact [email protected].

5. Responsible disclosure

If you believe you have found a security vulnerability, please report it to us privately and give us a reasonable opportunity to fix it before any public disclosure. We commit to:

• acknowledge your report, typically within 3 business days;
• provide a triage assessment and expected timeline, typically within 10 business days;
• keep you updated as we remediate; and
• credit you (with your permission) once the issue is resolved.

Please do not publicly disclose before we have remediated or 90 days have passed, whichever is sooner, and let us coordinate timing with you.

6. Scope

In scope

• The hosted Service, its API, console, widget, and edge.
• The open-source software in our repository.

Out of scope

• Social engineering, phishing, or physical attacks against our people or offices.
• Denial-of-service testing, automated scanning that degrades the Service, or spam.
• Findings that require a compromised device or a man-in-the-middle you control.
• Vulnerabilities in third-party services (report those to the third party).
• Reports of missing best-practice headers without a demonstrable impact.

7. Safe harbor

We will not pursue or support legal action against researchers who, in good faith, comply with this policy: who avoid privacy violations and service degradation, access only the minimum data necessary to demonstrate an issue, do not exfiltrate, alter, or destroy data, and give us a reasonable time to respond before disclosure. If in doubt about whether an action is authorized, ask us first. This authorization does not extend to third parties' systems or data.

8. How to report

Email [email protected] with a description, steps to reproduce, affected endpoints, and impact. Our machine-readable contact details are published at /.well-known/security.txt (RFC 9116). Please do not include third-party data in your report. We do not currently run a paid bug-bounty program, but we gratefully acknowledge researchers who help keep the Service safe.