Built to pass your security review.
Stockisto handles supplier and retailer network data for B2B customers across Europe. Here is concretely how we isolate, encrypt, and protect that data — and 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
Access tokens
15-min, HttpOnly cookie
Your data is walled off from every other customer
Stockisto is multi-tenant by design, and isolation is enforced in the data layer — not left to application code to remember.
Global tenant query filter
Every tenant-scoped entity carries a TenantId, and the database context applies a global query filter so reads are automatically constrained to the current tenant. There is no code path where a query silently returns another tenant's rows.
Insert-time guard
A SaveChanges interceptor refuses to persist any tenant-scoped record with a missing or empty TenantId, so data cannot be written into an ambiguous or wrong-tenant state.
Cross-tenant tests in CI
Dedicated cross-tenant test suites assert that one tenant cannot read or mutate another tenant's data across modules. These run in the CI pipeline on every change, so isolation is continuously regression-tested.
Tokens the browser can't leak
Sessions are built on short-lived JWTs delivered in a cookie that JavaScript can never read, which removes the most common token-theft vector.
HttpOnly, Secure cookie
The access token is issued in an HttpOnly and Secure cookie. Because it is HttpOnly, page scripts cannot read it, so an XSS bug cannot exfiltrate the session token. The API reads the token from the cookie rather than relying on a JavaScript-accessible header.
Short-lived access tokens
Access tokens are signed with HS256 and default to a 15-minute lifetime. A leaked token is only valid for a short window before it expires.
Refresh rotation with reuse detection
Refresh tokens rotate on every use: redeeming a refresh token atomically replaces the stored value. Presenting an already-used (old) refresh token no longer matches and is rejected, so token replay is detected and shut down.
Google OAuth & magic links
Customers can sign in with Google OAuth or with single-use, time-limited magic links. Magic links are issued through the framework's one-time token provider, so a link cannot be replayed after it has been redeemed.
Role-based access, scoped to what each user owns
Access is governed by explicit roles plus data scoping, so a user only ever sees the slice of the network they are entitled to.
Defined roles
The system ships a fixed set of application roles — SupplierAdmin, RetailerAdmin, and StockistoAdmin for administrative access, alongside scoped roles such as SupplierViewer and RetailerDataManager for narrower, read- or data-management access.
Scoped data roles
Scoped roles are bound to a specific entity (for example, a retailer-data role is tied to a single retailer via a scope claim carried in the token). Authorization is checked on the server for every request — the UI never grants access the API hasn't already enforced.
Encrypted in transit, hardened at the edge
All traffic runs over TLS, and every API response carries a set of security headers to limit the blast radius of browser-side attacks.
TLS & HSTS
Traffic is served over HTTPS, and responses set Strict-Transport-Security (HSTS) with a one-year max-age and includeSubDomains, instructing browsers to refuse plaintext connections. HTTPS is additionally enforced at the CDN / edge layer.
Security headers on every response
A dedicated security-headers middleware applies a restrictive Content-Security-Policy (default-src 'none' for JSON API responses), X-Frame-Options: DENY to block clickjacking, X-Content-Type-Options: nosniff, and a strict-origin-when-cross-origin Referrer-Policy.
Rate limiting & abuse detection
Requests are governed by sliding-window rate limiters, partitioned per tenant and per client. Repeated rejections trigger automatic, time-boxed blocking so abusive or runaway clients are contained without affecting legitimate traffic.
EU-hosted, minimised, and under your control
Stockisto is built for European B2B customers, with data residency, minimisation, and subject-rights handling treated as defaults rather than add-ons.
EU data residency
Production data is hosted in the EU (Sweden Central region), keeping customer data within European jurisdiction.
Encryption at rest & in transit
Data is encrypted in transit via TLS and encrypted at rest using the platform's managed storage encryption.
Data minimisation & erasure
We collect only the data needed to run the discovery and analytics product, and we support deletion of customer and end-user data on request to honour erasure rights under the GDPR.
Audit logging & DPA
Tenant-level administrative actions are recorded to a tenant event log, and records carry maintained timestamps for change tracking. A Data Processing Agreement (DPA) is available for customers who require one.
Found a vulnerability? Tell us.
We welcome good-faith security research. If you believe you've found a vulnerability, email us with the details and we'll acknowledge your report, work the fix, and coordinate disclosure. Please give us a reasonable window to remediate before going public.
security@stockisto.comThe questions a reviewer actually asks.
Straight answers on isolation, hosting, authentication, and how to report an issue — written for the person signing 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 is tagged with a tenant identifier, and a global query filter constrains every read to the calling tenant. An insert-time guard blocks writes that lack a tenant, and a suite of cross-tenant tests runs in CI to prove that no tenant can reach another's data. It is not something individual queries have to remember to do.
Where is our data hosted?
In the European Union, in the Sweden Central region. Data is encrypted in transit over TLS and at rest using managed storage encryption. We're happy to 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 in an HttpOnly, Secure cookie, so the token is never exposed to page JavaScript and can't be stolen by an XSS bug. Refresh tokens rotate on every use and are revoked if an old one is replayed, which detects and stops token reuse.
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, and scoped roles are pinned to a specific entity through a claim in the token. Every authorization decision is enforced on the server, not just hidden in the UI.
What protects the API itself?
All traffic is TLS-only with HSTS. A security-headers middleware sets a restrictive Content-Security-Policy, X-Frame-Options: DENY, nosniff, and a strict referrer policy on every response. Sliding-window rate limiting and automatic abuse blocking protect against floods and credential-stuffing-style traffic.
How do we report a security issue?
Email security@stockisto.com with the details. We welcome good-faith reports, will acknowledge your message, and will work with you on a fix and a coordinated disclosure timeline. Please give us a reasonable window to remediate before any public disclosure.
Need our security pack or a DPA?
Book a call and we'll walk your security and procurement teams through our controls, answer the questionnaire, and provide a Data Processing Agreement.