Security

Data source credentials are encrypted at rest. Your Notion token is encrypted with AES-256-GCM before it reaches the database, using a 256-bit key held only in the server environment — never in the database, never in the source tree. Each value gets a fresh random 96-bit IV. The cipher is authenticated, so a tampered ciphertext fails to decrypt rather than decrypting to something wrong. Anyone reading a database dump gets ciphertext and nothing else — with no caveat: the read paths no longer accept a plaintext token at all, so a row that is not encrypted does not work rather than working quietly.

Those tokens are decrypted in memory only for the duration of a single API call. They are never sent to the browser, never written to a log, and excluded from your data export.

Everything is served over HTTPS.

Accounts use email and password. The password is stored as a hash, never in plain text. Sessions are token-based, and each session record keeps the IP address and user-agent of the device that signed in, so an unfamiliar sign-in is visible. Resetting a password destroys every session on the account, including the attacker's. Reset links expire in one hour and work exactly once.

An embed URL is itself the credential for a private chart, so it is treated as a secret: embed pages send no referrer at all, not even same-origin, and run under a locked-down Content-Security-Policy that frames them into the app and Notion and nowhere else. The password reset page does the same.

Error monitoring runs with Sentry's "send default PII" switched off, and every outbound event first passes through a scrubber that redacts embed tokens, share tokens and password reset tokens from URLs, error messages, breadcrumbs and span data.

Sign-up, sign-in, password change, password reset and embed requests are rate limited through Upstash Redis.

Security-relevant actions — password changes, password resets, account deletion, plan overrides, admin impersonation — are written to an audit log with the acting user's ID and a timestamp. Deleting an account does not erase those rows; an audit log you can erase is not an audit log.

Notion row content. Row values are fetched on demand and held in a short-lived server cache that expires on its own timer, between 30 and 300 seconds depending on plan. They are never written to our database.

Notion page content. We read a connected database's schema and its rows through the Notion API and nothing else — no page bodies, no images, no comments, no database you did not connect. We make no write calls at all.

Card numbers, CVCs and bank details. Checkout and the billing portal are hosted by our payment processor; that data never touches our servers.

Analytics and tracking. No analytics product, no advertising pixel, no behavioural tracking, no cookie banner because there is nothing to consent to. The only usage number we keep is a per-chart view counter.

One honest exception, and it is deliberate rather than accidental: an uploaded CSV is stored in full, because there is no upstream to re-fetch it from. It is capped at 5 MB and 50,000 rows, and deleting the connection or the account deletes it.

No SOC 2 report. No ISO 27001 certification. No external penetration test. No 24/7 on-call rotation. No security team.

Chartosaurus is built and run by one person. The controls in section 1 are real and you can hold us to them; the certifications above are not, and we will not imply otherwise to get through a procurement form. If your review requires any of them, this is the page that saves you the meeting.

Detection depends on error monitoring and on our own checks, not on someone watching a dashboard overnight. If something breaks at 3am, it is seen in the morning.

Send it through the Support page, which lists the address that is actually monitored. Please do not open a public issue or post it publicly before we have had a chance to fix it.

Include enough for us to reproduce it: the steps, the affected URL or endpoint, what you expected and what happened instead, and what an attacker could actually do with it. A proof-of-concept request, a short screen recording, or the exact payload all help. If it depends on a specific account state, say which.

We confirm receipt within 2 business days. One person reads that inbox, so there is no triage queue and no ticket number — you will get a reply from the person who will fix it.

If you research in good faith and stay inside the scope in section 6, we will not pursue legal action against you, will not report you, and will treat your report as an authorised test. If a third party brings a claim about research that followed these rules, we will say publicly that it was authorised.

We credit reporters who want credit — tell us the name or handle to use. If you would rather stay anonymous, that is fine too.

There is no paid bug bounty. No money, no swag, no points. We would rather be straight about that up front than have you find out after the work.

In scope: chartosaurus.com, the application behind it, its API and its embed endpoints.

Out of scope: the systems of our sub-processors — our hosting, payment, email, error monitoring and rate limiting providers each run their own programme, and reports about them belong with them, not with us.

Also out of scope: denial of service, volumetric or load testing of any kind; social engineering or phishing aimed at the operator, at any customer, or at a sub-processor's support staff; physical attacks; spam; and raw automated scanner output with no demonstrated impact. Missing best-practice headers, weak cipher suggestions and version disclosure are not vulnerabilities unless you can show what they let you do.

Test against your own account and your own data only. The moment a test would touch another customer's account, data, chart or embed, stop and report what you have. Do not modify or delete data that is not yours, and do not exfiltrate more than the minimum needed to prove the finding — one record is proof, a thousand is an incident.

Keep automated traffic to a rate a normal user could produce, and do not attempt to degrade the service for anyone else.

Please give us a reasonable window before publishing. We ask for 90 days from the day you report, which is the industry norm, and we will tell you as soon as it is fixed — usually well before that. If a fix is genuinely going to take longer, we will say so and explain why rather than go quiet.

Once it is fixed you are free to publish. We are happy to review a draft for accuracy if you want a second pair of eyes, and we will not ask you to change anything except a factual error.

Vulnerabilities, account questions, billing, privacy and security questionnaires all reach the same person. The Support page is the single route in, and it is the route published at /.well-known/security.txt. Receipt is confirmed within 2 business days.

There is no separate security alias: one inbox that is read beats a second address that is not.