Security
Last updated 5 August 2026
Access to your store
Sideby requests exactly two OAuth scopes, both read-only: users:read and
products:read. It holds no write scope, so there is no code path, and no
possible bug, by which it could alter a product, an order, a customer or a setting.
It never reads orders or customers, subscribes to no webhooks, and makes no outbound call to your store on a shopper's behalf.
Tokens
Your store's access token is held server-side only. It is never sent to a browser, never embedded in the storefront script, and never appears in a public API response, a log line or an error message.
Session security
The app runs embedded in your OpoShop admin. A session is minted only after ownership of the store is proven using the credential the caller themselves supplied , either a verified identity lookup with that token, or the platform's own validation of it during an authorization exchange signed with our client secret.
There is deliberately no fallback that re-checks ownership using a token we already hold. Such a check proves our token is valid; it proves nothing about who is asking. Anything unproven results in a connect prompt and no session.
Tenant isolation
Every record, configuration, hand-written values, counters, is scoped to a single store. A user account is unique per (owner, store) pair, so an owner who installs Sideby on two stores gets two independent accounts and two independent data sets. There is no API route that accepts a store identifier from the caller; the only store a request can reach is the one its session is bound to.
A boot-time audit verifies the index state that enforces this and reports any residual cross-store sharing.
The public endpoints
Three endpoints are reachable without authentication, because the storefront needs them:
- Configuration, returns the sheet's labels, rows and styling for a store. It is a hand-built allow-list; nothing is passed through automatically, so a field added to the settings later cannot leak by omission. An unknown, uninstalled or switched-off store returns only
{ enabled: false }. - Merchant-written values, returns only the values the merchant chose to publish, only for the specific products asked about, capped at that store's own limit, and only for rows that are live on the sheet.
- Event beacon, accepts a counter increment and returns immediately. It writes integers only.
All three are rate-limited per store and per client, and none of them can read or write anything belonging to a different store.
Shopper privacy by construction
The database holds no field that could identify a shopper, not an IP address, not a user agent, not a session id, not a cookie. This is a schema property rather than a policy promise: there is nowhere to put such a value.
Merchant cost data
Your storefront's public product data includes cost, margin and profit for each variant. Sideby reads named fields only and denies those by name in two independent places, the storefront script and the server-side settings validator, so no configuration, mistaken or deliberate, can put them in front of a shopper.
Transport and infrastructure
- All traffic over TLS; HTTP is redirected.
- Strict security headers, with framing limited to the OpoShop admin domains that need to embed the app.
- Malformed input is rejected with a client error, never a server error.
- Secrets are held as deployment secrets, never in source control.
Reporting a vulnerability
Email brandon@tryfound.io with the detail needed to reproduce it. We will acknowledge within two business days. Please do not test against a store you do not own.