Security & threat model

Architecture in one paragraph

Chartstone is a desktop app, not a SaaS. Your NetSuite session lives in a sandboxed Electron browser on your machine. A small HTTP server, also on your machine, exposes endpoints (SuiteQL, saved searches, RESTlet calls, schemas) bound to 127.0.0.1 behind a bearer token. Local clients (your scripts, your AI agent, Excel, curl) talk to that server. NetSuite responses go straight from the embedded browser to the calling client and never leave your computer through Chartstone.

What stays local

• Your NetSuite session cookie. Stored in the Electron sandboxed session, scoped to *.netsuite.com. Chartstone never reads or transmits the cookie value.
• Every NetSuite response. SuiteQL rows, saved-search results, RESTlet payloads, record schemas — returned to the local caller, never POSTed off your machine by Chartstone.
• The request log. Lives in your user data directory, retained for the number of days you configure (default 30), purged on a rolling basis.
• Your bearer token. Random per install, stored in your OS keychain via safeStorage when available, fallback file mode 0600 on disk.

What touches the network — and why

Chartstone makes outbound HTTPS requests on its own behalf in exactly three places. Everything else is your NetSuite session talking to NetSuite.

1. Subscription verification. On startup and once per day, the app POSTs your license key (or, in the email-fallback flow, your email) to chartstone.io/verify/. The response is a yes/no plus the email on file. Nothing about your NetSuite account is in the request.
2. Announcements feed. The app fetches chartstone.io/announcements/ at launch to show release notes and important notices. The request includes no identifiers.
3. Updates. macOS and Windows installers are downloaded directly from the signed installer host (chartstone.io). Code-signature verification is enforced by the OS, not by us.

Local API hardening

• Loopback bind. The server listens on 127.0.0.1. It is not reachable from your LAN, VPN, or the public internet. A coworker on the same Wi-Fi cannot connect to it.
• Bearer token on every request. A 256-bit random secret minted on first launch. Constant-time compared with crypto.timingSafeEqual — no short-circuit on length mismatches.
• CORS pinned to opt-in origins. The default is no cross-origin access; you can allowlist specific local tools (e.g. a localhost Next.js dev server) from Preferences.
• No persistent server in the background. The HTTP server runs only while the Chartstone window is open. Quit the app, the port is free.
• Server-side input validation. Endpoints reject shape-invalid payloads before any NetSuite call; SuiteQL is sent as a single bound string, no query templating with user-controlled fragments outside the bound value.

Subscription & billing

• Stripe handles all card data. Chartstone servers never see card numbers, CVVs, or names on card. Checkout happens on Stripe’s own domain (buy.stripe.com); we receive only the customer and subscription IDs and the billing email via webhook.
• Webhook signature verification. Every Stripe webhook hit verifies the Stripe-Signature HMAC against our shared secret with a constant-time comparison; replays are blocked by an event-ID idempotency table.
• License keys. 128 bits of entropy (cs_live_ + 32 lowercase hex chars). Stored in the customer-keys table on chartstone.io, paired only with the customer ID, subscription ID, and email. The app stores the key in your OS keychain, not in plaintext alongside other settings.
• Verify endpoint is rate-limited. Five requests per minute per IP. Prevents using the yes/no response to enumerate keys or customers.
• Key rotation. If a key is leaked or shared, we can rotate it in place — the old value stops working immediately, the customer gets a fresh key via email, and the subscription itself is unchanged.

What we do not claim

We’d rather be specific about gaps than oversell. As of launch:

• Chartstone has not been through a SOC 2, ISO 27001, or third-party penetration test. The threat model above is self-attested; the source is small enough that a careful reader can audit it directly, and we’ll publish a third-party review when the budget supports it.
• We do not encrypt the on-disk request log at rest beyond normal OS file permissions. If your machine is fully compromised, an attacker with your user account can read the log. Disk-level encryption (FileVault, BitLocker) is the right control here.
• We do not enforce machine-binding on license keys. A key verified on one machine will verify on another. We chose this deliberately: it lets you move between laptop and desktop without a support ticket, and the alternative creates more friction than it prevents leakage at this audience and price point.
• We do not inspect or sandbox the SuiteScript you submit via the /script endpoint. It runs with the permissions of your NetSuite role. If your role can delete records, scripts you write can delete records. Treat /script like a SuiteScript debugger session, not like a guarded API.

Reporting a vulnerability

If you find a security issue — in the app, the local server, the chartstone.io endpoints, or the install pipeline — please email tim@suitestep.com with details and, if possible, a reproducer. Do not file a public GitHub issue. We’ll acknowledge within one business day, ship a fix as quickly as the severity warrants, and credit you in the release notes if you’d like.

We don’t currently run a paid bug bounty, but a real finding will get a real thank-you and, where applicable, a comp Pro license.

More questions? See the FAQ, read the terms and privacy pages, or email tim@suitestep.com.