Trust, stated plainly.

Data isolation #

Overlay is multi-tenant. Every request is bound to a tenant on entry — either by hostname (a merchant's custom domain) or by session — and passes through getPosForTenant(req.tenant) before any read or write. There is no shared table with a tenant_id column. Each tenant's data lives in a namespaced path: their catalog, waitlist, holds, marketing history, and design config are all separate files or database rows keyed by tenant slug.

Unknown hostnames do not fall back to another tenant's storefront. They return a neutral "not configured" page. New API endpoints must resolve req.tenant; this is checked at code review.

Encryption #

In transit

All traffic to overlaypos.com, tenant subdomains, and merchant custom domains is served over TLS 1.2 or higher, terminated at Render's edge. HSTS is enabled. HTTP requests are redirected to HTTPS.

At rest

Application data is stored on Render-managed disks with provider-level disk encryption. Secrets (Square access tokens, SES credentials, Stripe keys, admin keys) live in Render environment variables and are never written to disk or checked into source control. Merchant passwords are hashed with bcrypt at cost 12.

Access controls #

Overlay has three concentric layers of access:

• Session tokens — merchants and their staff sign in with email and password; sessions are short-lived HTTP-only cookies. Password reset requires the current email on file.
• Per-tenant admin key — every tenant is issued a rotatable admin key that scopes API calls to that tenant. Admin keys never confer cross-tenant access.
• Master key — a single Overlay-operator secret guards super-admin endpoints (tenant provisioning, cross-tenant analytics, subprocessor management). It is held by the Overlay operator only and never issued to merchants.

Every /api/admin/* write requires either a valid session or the tenant's admin key. Unauthenticated write endpoints are refused at code review.

Deployment & code review #

Every push to the main branch runs the following before deploy:

• npm audit --omit=dev --audit-level=high — fails on any HIGH or CRITICAL CVE.
• node --check on every JavaScript file — no syntax regressions can reach production.
• npm test — unit tests and smoke tests must pass.
• ESLint on core files (currently warn-only; ratcheting to hard-fail).

Sensitive changes — authentication, checkout, tenant isolation, marketing sends — route through the staging branch at staging.overlaypos.com before production. Production redeploys during business hours (12 PM to 10 PM Central) are confirmed with the operator before push, except for hotfixes to a live incident.

Every commit is expected to observe:

• No unbounded express.json() handlers — every JSON body parser declares a limit.
• No unauthenticated write endpoints under /api/admin/*.
• No cross-tenant reads — every data access goes through getPosForTenant(req.tenant).

Mass-send guardrails #

Marketing sends touch thousands of customer addresses in a single request, so they carry their own guardrails. Every campaign that reaches more than one recipient runs through two mandatory checks before the send is authorized:

• Preflight validation — subject-line length capped at 78 characters; every calendar date in the body is checked against its stated weekday; all links are HEAD-requested for resolution; template placeholders ([First Name], [TBD], {{...}}) are refused; a preheader must be present.
• Duplicate-send guard — a same-subject campaign created within the last 15 minutes is refused, preventing accidental double-sends when the same script fires twice.

Both guards accept an explicit --force override for CLI operators. Skipping the guards in a new send script is treated as a bug, not a shortcut.

Monitoring & logging #

The server initializes Sentry at boot when SENTRY_DSN is set. A catch-all Express error middleware reports every 5xx with route, method, and tenant tags. Sensitive headers — authorization, cookie, x-admin-key, and square-access-token — are redacted before dispatch.

Structured logs are retained for 30 days at the platform level (Render) and are only accessible to Overlay operators over authenticated sessions. Logs never include full card numbers, full API tokens, or plaintext passwords.

Backups & retention #

Application state — catalog cache, waitlist, holds, marketing suppression, referrals, webhook ledger — is snapshotted daily by Render's managed disk backup and retained for 7 days. Point-in-time restore is available within that window. Source-of-truth records (Square catalog, Shopify products, WooCommerce inventory) live in the merchant's POS; Overlay treats them as a cache.

On account closure, tenant data is deleted within 30 days. Merchants can request an immediate export or purge at team@overlaypos.com.

Incident response #

The operator on call is reachable at team@overlaypos.com. A reported vulnerability is acknowledged within 48 hours. Confirmed HIGH or CRITICAL findings are patched within 14 days; MODERATE within 30. Security researchers who ask for credit in a public advisory receive it.

If a customer data breach is confirmed, affected merchants are notified within 48 hours with the scope, root cause, and remediation. Public incident notes are posted below.

Subprocessors #

Overlay uses the following third-party services to deliver the product. Each merchant chooses the payment and POS provider they already use; the rest are Overlay-operator infrastructure.

Subprocessor changes that affect where merchant data is processed are communicated by email 30 days before they take effect.

Incident history #

Public incidents are recorded here with root cause and remediation.

Known limitations #

We list what we don't yet have, because a security page that only lists strengths isn't useful.

• No formal SOC 2 attestation. Overlay has no SOC 2 Type I or Type II report. Merchants who require one should not consider Overlay compliant until it is issued.
• No external penetration test on file. Overlay has not been audited by an independent security firm.
• Multi-factor authentication is not yet required. The framework exists in the codebase; the UI is on the roadmap. Session cookies are the current auth boundary.
• Single-process server. The application runs as a single Node process. Horizontal scale requires migrating hot JSON stores (waitlist, holds, referrals, webhook ledger) to a database with transactions. This is a scale limitation, not a data-integrity limitation for current volumes.
• No SOC 2 or ISO 27001 badges. We won't display certifications we don't have.

If you're evaluating Overlay for a business that requires any of the above, tell us — we'll be direct about timelines.

Security roadmap #

These are the security investments we've committed to, ordered by priority. Dates are targets, not guarantees.

• NextMFA for merchant accounts. TOTP via authenticator app; opt-in first, then required for admin roles.
• NextAdmin-key rotation UI. Self-serve rotate + revoke from the tenant dashboard.
• NextESLint ratchets to hard-fail. No warn-only rules on core files.
• PlannedThird-party penetration test. Scope: authentication, checkout, tenant isolation, marketing send.
• PlannedDatabase migration for hot state. Move waitlist, holds, and webhook ledger from JSON to Postgres with transactions.
• PlannedFormal audit logs. Immutable append-only log of every admin write, exportable per tenant.
• LaterSOC 2 Type I readiness. Requires the two items above first; not a near-term promise.
• LaterCustomer data-subject portal. Self-serve export and deletion for merchant customers, without needing to email support.

Report a vulnerability #

Email team@overlaypos.com. Do not open a public issue on any of our repositories. We acknowledge within 48 hours, patch HIGH/CRITICAL within 14 days, and MODERATE within 30. If you'd like credit in a public advisory, mention it in your report.