Security

Overview

HolyDocs is built on a small, modern stack designed to keep the attack surface narrow. The platform runs on Cloudflare’s edge network, which provides in-built DDoS mitigation, WAF, and rate limiting before traffic ever reaches our application code. We treat security as a product feature: it appears in our roadmap, our retros, and our on-call playbooks.

Infrastructure

HolyDocs runs entirely on Cloudflare. The dashboard, API, and documentation renderer are deployed as Cloudflare Workers. Customer Content is stored in:

• Cloudflare D1 — SQLite-backed relational storage for structured data, projects, and metadata.
• Cloudflare R2 — object storage for built documentation assets, images, and exports.
• Cloudflare KV — low-latency key-value cache used for search indexes and configuration.
• Cloudflare Vectorize — vector database for semantic search embeddings.

Cloudflare operates data centers in 300+ cities globally; documentation traffic is served from the nearest edge location to the visitor. Cloudflare maintains independent third-party attestations including SOC 2 Type II, ISO 27001, ISO 27018, PCI DSS, and FedRAMP for portions of its platform; see Cloudflare’s trust hub.

Encryption

• In transit: TLS 1.3 is enforced on all HolyDocs endpoints, with HSTS preloaded on holydocs.com. Outbound calls to subprocessors use TLS 1.2+ with modern cipher suites.
• At rest: Customer Content stored in Cloudflare R2 and D1 is encrypted with AES-256 at the disk level. Backups are encrypted with the same algorithm and keys are managed by Cloudflare under its KMS controls.
• Secrets: API keys, OAuth client secrets, and signing keys are stored in Cloudflare Secrets Store and never written to source code, logs, or environment files in committed repositories.

Authentication

End-user authentication is handled by Better Auth, with support for:

• email + password with bcrypt password hashing;
• OAuth sign-in with GitHub and Google;
• magic-link email login;
• CLI device login with short-lived device codes;
• single sign-on via SAML for the Business and Enterprise plans, including just-in-time provisioning;
• passkeys (WebAuthn) on platforms that support them.

Session cookies are HttpOnly, Secure, and SameSite=Lax by default; sensitive actions (such as changing payment method) require re-authentication. CSRF tokens protect state-changing endpoints. Failed login attempts are rate-limited at the edge.

Access Controls

Internal access to production systems follows the principle of least privilege. HolyDocs personnel access production only through Cloudflare’s zero-trust access controls, with mandatory multi-factor authentication. Production access is time-limited, logged, and reviewed quarterly. Customer Content is not accessed by personnel except as needed to operate the Service, respond to a support request that the Customer has initiated, or investigate a security or abuse issue.

Within a Customer workspace, role-based access controls (Owner, Admin, Editor, Viewer) restrict who can change settings, deploy documentation, manage billing, or invite new members. Audit logs of administrative actions are available to workspace Owners and Admins on the Business and Enterprise plans.

Vulnerability Management

• Dependency scanning via GitHub Dependabot and automated alerts on vulnerable packages; critical vulnerabilities are triaged within one business day.
• Static analysis with GitHub CodeQL on all production codepaths; findings are tracked to remediation.
• Code review required on all changes before merging to production branches.
• Pre-merge CI runs the test suite and type-checks on every pull request.
• Periodic penetration tests conducted by qualified third parties; remediation is tracked to closure.

Incident Response

We maintain an incident-response runbook with a defined severity rubric, paging thresholds, and a 24/7 on-call rotation. The on-call engineer is paged for any production incident that affects the dashboard, API, or rendering of documentation sites. Material customer-impacting incidents are reported on our public status page at status.holydocs.com, and post-incident reports are published for significant outages.

For Personal Data Breach notification specifically, see Section 15 of the Privacy Policy and Section 9 of the DPA.

Compliance & Roadmap

• GDPR & UK GDPR — supported today through our DPA, with SCCs incorporated by reference for international transfers.
• CCPA / CPRA — supported today; see the California section of our Privacy Policy.
• SOC 2 Type II — attestation is in progress. We will publish our most recent report through a signed NDA on request to Enterprise prospects and customers once available.
• ISO 27001 — on the medium-term roadmap; demand-driven.
• HIPAA — HolyDocs is not currently HIPAA-eligible. Do not upload PHI to the Service.

Data Protection

Customer Personal Data is protected by the technical and organizational measures described in Annex 1 of the DPA. Backups are taken daily and retained for 35 days. Backup restoration is tested at least semi-annually. Hardware decommissioning is the responsibility of Cloudflare and follows their certified disposal procedures.

Responsible Disclosure

We welcome reports from the security research community. If you believe you have found a security vulnerability in HolyDocs, please email security@holydocs.com with:

• a description of the vulnerability and its potential impact;
• step-by-step reproduction instructions;
• any proof-of-concept code or screenshots that help us reproduce the issue;
• your name (or pseudonym) if you would like to be credited.

Our security.txt file is published at api.holydocs.com/.well-known/security.txt per RFC 9116.

Safe Harbor

We will not pursue legal action against good-faith security researchers who:

• test only against accounts that they own or for which they have explicit authorization;
• do not access, modify, exfiltrate, or destroy data beyond the minimum necessary to demonstrate the issue;
• do not degrade the Service for other users (no DoS or load testing);
• do not perform social engineering against HolyDocs personnel or vendors;
• give us a reasonable opportunity to remediate before any public disclosure.

Bug Bounty

We operate an informal, invite-light bounty: valid reports that meet our disclosure guidelines are eligible for a monetary reward (paid via the method of the reporter’s choice) and a public thank-you, at our discretion. Severity is assessed using a CVSS-aligned rubric; rewards scale with impact, with critical authenticated-bypass and unauthenticated-RCE findings earning the largest amounts. We do not publish a fixed payout table; bounty decisions are at HolyDocs’ reasonable discretion and we may decline to reward issues that are duplicates, out-of-scope, or that have minimal real-world impact.

Contact

Security questions, vulnerability reports, or requests for our latest security documentation: security@holydocs.com.