Menu
Security & Trust

Built to pass your security review.

Stockisto holds your supplier and retailer network data. This page shows how we isolate, encrypt, and protect that data. It also tells you how to reach us if you find a problem.

Data residency

EU 路 Sweden Central

Encryption

In transit & at rest

Tenant isolation

Enforced in the data layer

Session tokens

15-min, HttpOnly refresh

Tenant isolation

Your data is walled off from every other customer

Stockisto is multi-tenant by design. Isolation is enforced in the data layer, so application code cannot forget it.

Global tenant query filter

Every tenant-scoped record carries a TenantId. A global query filter constrains every read to the current tenant. No code path can silently return another tenant's rows.

Insert-time guard

An interceptor checks every write. It refuses to save a tenant-scoped record with a missing or empty TenantId. Data cannot be written into an ambiguous or wrong-tenant state.

Cross-tenant tests in CI

Dedicated test suites prove that one tenant cannot read or change another tenant's data. They run in CI on every change, so isolation is regression-tested continuously.

Authentication

Short-lived sessions, hardened against theft

Sessions are built on short-lived JWTs. The refresh token lives in an HttpOnly cookie that page scripts can never read. A leaked access token expires within minutes.

HttpOnly refresh token, short-lived access token

The refresh token is the durable credential. It is stored in an HttpOnly, Secure cookie that page scripts cannot read. The access token sits in a separate Secure cookie the app reads to call the API. That is a deliberate, documented tradeoff. Its short lifetime and automatic rotation limit the risk. To compromise a session, an attacker must steal a token that expires within minutes.

Short-lived access tokens

Access tokens are signed with HS256 and expire after 15 minutes by default. A leaked token is valid only for that short window.

Refresh rotation with reuse detection

Refresh tokens rotate on every use. Redeeming one atomically replaces the stored value. A replayed old token no longer matches and is rejected, so token replay is detected and shut down.

Google OAuth & magic links

You can sign in with Google OAuth or with single-use, time-limited magic links. The framework's one-time token provider issues each link, so a redeemed link cannot be replayed.

Authorization

Role-based access, scoped to what each user owns

Explicit roles plus data scoping govern access. Each user sees only the slice of the network they are entitled to.

Defined roles

The system ships a fixed set of roles. SupplierAdmin, RetailerAdmin, and StockistoAdmin cover administrative access. Scoped roles such as SupplierViewer and RetailerDataManager grant narrower read or data-management access.

Scoped data roles

A scoped role is bound to one entity. For example, a retailer-data role is tied to a single retailer through a scope claim in the token. The server checks authorization on every request. The UI never grants access the API has not already enforced.

Transport & hardening

Encrypted in transit, hardened at the edge

All traffic runs over TLS. Every API response carries security headers that limit the blast radius of browser-side attacks.

TLS & HSTS

Traffic is served over HTTPS. Responses set Strict-Transport-Security (HSTS) with a one-year max-age and includeSubDomains, so browsers refuse plaintext connections. The CDN edge also enforces HTTPS.

Security headers on every response

A dedicated middleware applies security headers to every response: a restrictive Content-Security-Policy (default-src 'none' for JSON responses), X-Frame-Options: DENY against clickjacking, X-Content-Type-Options: nosniff, and a strict-origin-when-cross-origin Referrer-Policy.

Rate limiting & abuse detection

Sliding-window rate limiters govern requests, partitioned per tenant and per client. Repeated rejections trigger automatic, time-boxed blocking. Abusive or runaway clients are contained without affecting legitimate traffic.

Data & GDPR

EU-hosted, minimised, and under your control

Stockisto is built for European B2B customers. Data residency, minimisation, and subject rights are defaults, not add-ons.

EU data residency

Primary processing runs in the EU (Azure Sweden Central). A small set of US sub-processors operates under EU Standard Contractual Clauses.

Answer provenance

Shopping surfaces and assistants increasingly ask where a product is in stock nearby. An answer carries more weight when it names the retailer that confirmed the stock, and the date.

Encryption at rest & in transit

Data is encrypted in transit with TLS. At rest, the platform's managed storage encryption applies.

Data minimisation & erasure

We collect only the data needed to run the discovery and analytics product. You can request deletion of customer and end-user data. That honours erasure rights under the GDPR.

Audit logging & DPA

Tenant-level administrative actions are recorded in a tenant event log. Records carry maintained timestamps for change tracking. A Data Processing Agreement (DPA) is available if you require one.

Responsible disclosure

Found a vulnerability? Tell us.

We welcome good-faith security research. If you believe you have found a vulnerability, email us the details. We will acknowledge your report, work the fix, and coordinate disclosure. Please give us a reasonable window to remediate before you go public.

security@stockisto.com
Security FAQ

The questions a reviewer actually asks.

Straight answers on isolation, hosting, authentication, and reporting an issue. Written for the person who signs off on the vendor review.

How do you keep one customer's data from leaking into another's?

Isolation is enforced in the data access layer. Every tenant-scoped record carries a tenant identifier. A global query filter constrains every read to the calling tenant. An insert-time guard blocks writes that lack a tenant. Cross-tenant tests run in CI to prove no tenant can reach another's data. Individual queries never have to remember any of it.

Where is our data hosted?

In the European Union, in the Sweden Central region. Data is encrypted in transit over TLS and at rest with managed storage encryption. We can confirm the specifics and provide a Data Processing Agreement as part of your review.

How does authentication work, and how do you handle session tokens?

Users sign in with email magic links or Google OAuth. The API issues a short-lived (15-minute) JWT access token. The refresh token is stored in an HttpOnly, Secure cookie that page scripts cannot read. Refresh tokens rotate on every use, and a replayed old token is revoked and rejected. A leaked access token is useful only for minutes.

Who can see what inside an account?

Access is role-based. Administrative roles (SupplierAdmin, RetailerAdmin, StockistoAdmin) and narrower scoped roles control what each user can do. A scoped role is pinned to one entity through a claim in the token. The server enforces every authorization decision. Nothing is enforced only in the UI.

What protects the API itself?

All traffic is TLS-only with HSTS. Every response carries a restrictive Content-Security-Policy, X-Frame-Options: DENY, nosniff, and a strict referrer policy. Sliding-window rate limiting and automatic abuse blocking contain floods and credential-stuffing traffic.

How do we report a security issue?

Email security@stockisto.com with the details. We welcome good-faith reports. We will acknowledge your message, work with you on a fix, and coordinate a disclosure timeline. Please give us a reasonable window to fix the issue before any public disclosure.

Does your embeddable Locator widget need its own cookie banner on our site?

The widget sets no cookies. It uses localStorage for the postcode you enter and its coordinates, cached brand styling, and the loading shape of a saved embed (widget type, view and settings). In sessionStorage, stockisto.result-intent.<brandSlugOrSupplierId>|<sku>|<retailerId> holds random result ids that prevent duplicate analytics events after a tab is restored. stockisto:gh-intent:<supplierId> holds the chosen installer id. stockisto:gh-intent:<supplierId>:<installerId> holds an idempotency key, a salted fingerprint of the submitted request body and the retailer id. This lets a retried installer request reuse its key without creating a duplicate lead. The fingerprint is derived from the submitted form; the record does not store the name or email address as text. The pending-request record is cleared after a successful submission, a replay or an intake conflict. The installer-selection key and remaining sessionStorage entries last for the tab session. Embed credentials and the analytics session id stay in memory. Analytics are off unless your site sets data-analytics-consent="true"; connect that setting to your own consent choice. See our Cookie Policy for storage on stockisto.com.

Vendor review

Need our trust pack or a DPA?

Book a call. We will walk your security and procurement teams through our controls, answer the questionnaire, and provide a Data Processing Agreement.

Or email security@stockisto.com directly.

cebf50c 路 2026-10-05 22:57