Trust and security

Encryption

Both sites are served over HTTPS by Vercel, which terminates TLS and redirects plain HTTP. The dashboard sends a two-year HSTS header, denies framing, and sets nosniff and referrer policies. Calls to your store, your PIM and every vendor are HTTPS; connectors refuse plain-HTTP URLs and private network addresses.

At rest, the database host encrypts storage. On top of that, every credential you give us is encrypted by the application with AES-256-GCM before it is written: store and PIM tokens, SFTP secrets, Google OAuth refresh tokens. A stored value without the encrypted-format marker is refused, never used. Credentials are decrypted only inside the job that needs them and are never returned to the browser.

API keys are stored as SHA-256 hashes and shown once. Sign-in codes are stored hashed.

Authentication and access

Sign-in is passwordless: a one-time code by email, single use, short expiry, hashed at rest. There is no password to leak. Changing the account email needs a code from the current address first; deleting an account needs a confirmation link opened in the signed-in browser.

A workspace has one owner. Members are invited by email and work on the workspace's catalogs, feeds and measurement. Plan, billing, workspace settings, membership, API keys and bulk approvals are owner-only, checked on the server. Every database query is scoped to the workspace owner, so no request can read another workspace's rows.

API keys carry scopes (catalog:read, readiness:read, feeds:read, jobs:write), read exactly what the owner sees, and can be revoked at any time. Production systems are held by the two founders only, with MFA on every account that offers it.

Rate limiting

Limits are counted in the database, so they hold across serverless instances rather than per process.

• Sign-in and account endpoints: 100 requests per 10 seconds, and 3 per minute for the email-code endpoints.
• Public API: 120 requests per minute per key. Excess requests get a 429 with a Retry-After header.
• Public readiness scans: throttled per address (hashed) and globally.
• Scheduled jobs require a bearer secret; without it the route refuses to run.

Data retention and deletion

Your catalog, enrichment, feeds and measurement history stay for as long as your account exists. Operational rows are pruned by a nightly job:

You delete your account yourself from Settings. On confirmation any Stripe subscription is cancelled first, then the account row is deleted and the database cascades through everything it owns: workspace, members, catalogs, products, enrichment, feeds and artifacts, deliveries and their secrets, store connections, API keys, jobs and measurement history. Deleted rows persist in the host's backups until its retention window rolls past. Requests to delete specific data by email are handled within ten business days.

Backups

Neon, the Postgres host, keeps automated backups with point-in-time restore for the window its plan provides. We do not take separate backups. We have not yet run a restore drill; the first one is scheduled with the first enterprise agreement, and this page will say when it happened.

Subprocessors

The services that run the platform and what each one sees. All are in the United States.

Your own store or PIM (Shopify, WooCommerce, Akeneo, Salsify) is read with the credentials you supply and, with your permission on plans that include write-back, written to. Review platforms are read through their public widget endpoints; no customer data is sent to them. Product text goes to model providers under API terms that exclude training.

Access review

Every quarter, and whenever someone joins or leaves, the CTO lists the human accounts on each production system, confirms each belongs to a current founder or employee, confirms MFA, rotates any secret that was shared outside its system, and records the date and outcome. Offboarding happens the same day. The first inventory was written on September 5, 2026: two founders, nobody else.

Incident response

An incident is anything that exposes customer data to someone who should not see it, lets someone act as a customer they are not, or takes the service down for more than an hour. The steps, in order:

• Acknowledge: tell the other founder, open a private incident issue with the time noticed.
• Contain: revoke affected keys or sessions, rotate the secret, disable the route or roll back, before the full picture is known.
• Assess: work out which workspaces and which data were affected, and write it down as you go.
• Notify: affected customers are emailed within 72 hours of confirming an incident that touched their data, with what happened, what we did, and what they should do.
• Fix: ship the change that removes the cause, with a test that would have caught it.
• Write it up: a short post-incident note within a week; timeline, cause, what changed.

Alerts today come from Vercel's cron failures, the backend's job-failure logs, Stripe and Resend, and people writing in. There is no dedicated monitoring product yet.

Responsible disclosure

If you find a vulnerability, email support@masirahq.com with "security" in the subject. Include the steps to reproduce and, if you can, your own workspace id. We acknowledge within three business days, keep you informed while we fix it, and credit you if you want that. Please do not access data that is not yours, do not run denial-of-service tests, and give us a reasonable time to fix before publishing. There is no bug bounty program.

Audits

SOC 2 Type I audit available on request for enterprise agreements.

No auditor is engaged today and no penetration test has been commissioned. The policies above are written so that an audit engagement is short when a deal calls for one. Customers with a security questionnaire can send it to the contact address; the answers come from these documents.