Security, and how to report a vulnerability.

1. How we protect workspace data

• Workspace data is hosted in the United States: the database in us-east-1 (Amazon Web Services, N. Virginia, United States); application servers in Vercel's Washington, D.C. region (iad1).
• Access to workspace data is limited by membership and role, and checked in the database.
• Sign-in links are single use and expire. A step-up check runs before sensitive account changes. Sessions use a 30-day cookie, and signing out everywhere ends all sessions.
• API keys are stored only as hashes.
• Data is encrypted in transit (TLS) and encrypted at rest by our providers.
• Content security policy and security headers; no personal data in analytics events.
• Rate limits, abuse controls, logging, dependency monitoring, code review and vulnerability response.

The providers that run ClaraDB, what each receives and where, are listed on the subprocessors page. The data processing agreement sets out these measures as contract terms. No system is perfectly secure; we will tell affected users and authorities of a personal data breach as the law requires.

2. How to report a vulnerability

Email hello@claradb.com(opens in a new tab) with the subject "Security report: ClaraDB". Please include:

• the URL, API endpoint or feature affected;
• the steps to reproduce it, and what you expected to happen instead;
• the impact as you understand it (what data or action an attacker could reach);
• screenshots, requests or a short proof of concept, with any personal data removed;
• how you would like to be credited, if at all.

The same contact is published in machine-readable form at /.well-known/security.txt(opens in a new tab).

3. Scope

In scope:

• claradb.com, including the signed-in workspace at claradb.com/app;
• api.claradb.com, the ClaraDB API and its MCP server;
• sign-in, invitations, API keys, webhooks, evidence packs and supplier upload links.

Out of scope:

• the providers' own systems (Vercel, Cloudflare, Supabase, PostHog, Resend, Paddle): report those to the provider;
• denial of service, load or volume testing, and spam;
• social engineering, phishing, or physical attacks on people or offices;
• findings with no security impact, such as missing best-practice headers on a page with no data, or version banners alone;
• reports from automated scanners without a working proof of concept.

4. Rules for testing

• Use only accounts you created yourself, and test only against workspaces and data you own.
• Do not access, change, download or delete another customer's data. If you reach it by accident, stop, do not keep it, and tell us in your report.
• Do not disrupt the service, degrade performance for others, or persist access. Do not send email or messages to other users through ClaraDB.
• Do not use a finding to demand payment or any other benefit.
• Give us a reasonable opportunity to fix the issue before telling anyone else.

5. What to expect

• A first reply within 2 U.S. business days (Monday to Friday, excluding U.S. federal holidays).
• An assessment of the report and, where it is valid, a plan and an expected fix date.
• A note when the fix is live, and credit on this page if you want it.

6. Safe harbor

If you make a good-faith effort to follow this policy, we will treat your research as authorized, will not pursue or support legal action against you for it, and will work with you to understand and fix the issue. This does not authorize access to third-party systems or data, and it does not override a law or a court order.

7. Rewards

ClaraDB does not run a paid bug bounty. We credit researchers who ask for it on this page.

8. Acknowledgments

No reports have been acknowledged yet.

9. Contact

The Plain Works Co., Ltd.: hello@claradb.com(opens in a new tab) (subject "Security report: ClaraDB").

Other legal pages

• Terms of use
• Privacy notice
• Data processing agreement
• Subprocessors
• Billing and refunds