Top / Security

Security and Vulnerability Disclosure

Effective August 1, 2026 Version 1.0

Position

Fabla, LLC designs Fable on the assumption that it holds customers’ working data. This page sets out the technical measures in place, how we operate them, and how to report a vulnerability — including, plainly, where we stand on third-party certification.

Authentication and authorisation

1.: The Service runs behind a Cloudflare Access boundary. Unauthenticated requests reach neither the frontend nor the API — knowing the URL is not enough to use it.
2.: The application implements its own WebAuthn passkey authentication, and the Worker verifies the JWT issued by Cloudflare Access on every request.
3.: Connections to external services are authorised by you through OAuth 2.0 with PKCE. We never hold your passwords.

Protecting data

1.: Traffic is encrypted with TLS 1.2 or above. Stored data lives in Cloudflare D1 and R2, and refresh tokens are encrypted at the application layer before storage.
2.: Encryption keys are held as Worker secrets and are never written to the repository, logs or the browser.
3.: The constraint that no row is returned to anyone but its owner is enforced in both SQL and indexes, so cross-tenant reads are prevented structurally.

Secret management

1.: Secrets in commits are scanned automatically by Gitleaks, and CI fails on a detection.
2.: Dependency vulnerabilities are scanned continuously and updated according to severity.
3.: Access to production secrets is limited to those who need it for their work.

Change control and verification

1.: Every change must pass type checking, lint, Playwright end-to-end tests and screenshot review. If any of these fails, it does not merge.
2.: Database schema changes are forward-compatible by default and applied in an order that does not destroy existing data.
3.: The reasoning behind a change is recorded in the repository as an Architecture Decision Record.

Monitoring and incident response

1.: We define service-level objectives for uptime and p95 latency and alert on deviation. A daily report keeps the current state visible.
2.: On becoming aware of a security incident we establish the facts, determine scope, contain, recover and put a permanent fix in place — and record all of it.
3.: Where an incident amounts to a personal data breach, we notify affected users and the relevant supervisory authority within the period required by applicable law, or otherwise without undue delay.

Data location and subprocessors

1.: Data is processed on Cloudflare’s global network, including in the United States. Our principal subprocessors are listed in Article 6 of the Privacy Policy.
2.: Subprocessors are bound by contract to equivalent safeguards, and we supervise their performance.

Certification status

1.: We do not currently hold SOC 2 Type II or ISO/IEC 27001. On request we will provide our current control register, covering both planned certification and the compensating controls in place.
2.: For features using restricted Google API scopes, we follow the third-party security assessment (CASA) framework Google requires.
3.: We do not present certifications we do not hold as though we held them.

Responsible disclosure

1.: If you find a vulnerability, write to info@fabla-us.com. We give a first response within three business days and share a remediation plan according to severity.
2.: While researching, please do not access other users’ data, disrupt the service, attempt physical attacks or use social engineering. We will not take legal action over reports that stay within those limits.
3.: We do not currently run a bounty programme, but we are glad to credit you publicly if you would like that.

Business continuity

1.: Data is held on Cloudflare’s redundant infrastructure and snapshotted daily. Recovery procedures are documented and reviewed regularly.
2.: In case we cannot continue to operate, we provide a means for you to export your data in a machine-readable format.

Organisation and accountability

1.: Final accountability for security rests with the Authorized Person, and a day-to-day owner is named.
2.: Serious incidents have a direct reporting path to that owner, and no one is disadvantaged for reporting one.
3.: We keep an escalation path to outside specialists to sanity-check our judgement.

People and devices

1.: Everyone involved in developing or operating the Service is bound by contractual confidentiality obligations.
2.: Work devices require disk encryption, screen lock, and automatic operating-system and browser updates.
3.: Production access is granted only where the role requires it and is reviewed quarterly.

Encryption specifics

1.: Traffic uses TLS 1.2 or above, with 1.3 preferred, and legacy cipher suites disabled.
2.: Refresh tokens for external services are encrypted with AES-GCM before storage, with keys held as application secrets.
3.: We maintain a key-rotation procedure and reissue immediately on any suspicion of exposure.

Separating development and production

1.: Development and test environments never use production customer data; synthetic test data is used instead.
2.: Only changes that pass automated verification are deployed to production. No manual direct changes are made.
3.: Direct operations on the production database are logged and reviewed afterwards.

Backup and recovery objectives

1.: Data is snapshotted daily, with the last 30 days retained.
2.: We operate to a recovery point objective of 24 hours and a recovery time objective of 8 hours.
3.: Recovery procedures are documented and tested by an actual restore at least once a year.

Third-party risk

1.: Before adopting a new external service we assess data location, encryption, authentication and exit options.
2.: The assessment is recorded in a register, and equivalent safeguards are imposed by contract.
3.: When a serious vulnerability is disclosed, we determine our exposure and stop using the service if necessary.

Disposal of data

1.: Data deleted on request or at the end of an agreement is removed logically and then erased completely when the backup retention period expires.
2.: Where physical media is destroyed, we rely on the cloud provider’s disposal procedures.
3.: We confirm completion of deletion in writing on request.

Reporting a vulnerability

Fabla, LLC (Delaware Limited Liability Company)

2810 N Church St STE 89647, Wilmington, DE 19802, United States

Reports: info@fabla-us.com

A PGP key is available on request to the same address.

Handling of personal data is set out in our Privacy Policy .