Our positions
1. Settings are data, never code
On the Online Store, our apps run only through Shopify theme app extensions and never edit your theme files. Your settings reach the page as data and are never run as code, and no setting lets anyone add custom JavaScript, HTML or CSS.2. Ask for less, keep less
Each app requests only the permissions its features need. The safest shopper data is data we never hold, so our apps keep as little of it as they can.3. Trust the signature, not the request
Wherever Shopify signs a request, we check that signature and take your store’s identity only from it, never from anything a browser claims. Where Shopify can’t sign a request, we use a per-store key with the tightest limits we can set.4. Every store is its own boundary
Every read and write is limited to the store that made the request, so each merchant’s settings, data and credentials stay separate. Each app also keeps its own storage, and no app shares data with another.5. Credentials should be short-lived and contained
Access to your store should expire quickly, renew automatically and only ever work for your store.6. You stay in control and can see everything
Each app is a switch in your theme editor, and its permissions are listed in your Shopify admin. AI assistants connect only after a store admin approves them.7. Be fast and plain when something goes wrong
If an incident affects you, we contain it first, then tell you what happened, what was affected and what to do.Why we build this way
Most app security failures don’t come from a single bug. They come from an architecture that lets one compromised piece reach everything else: an internal tool that can push code to thousands of storefronts, or a setting that becomes a script. We rule those patterns out at the design stage. That’s why our apps are built on Shopify’s native surfaces: theme app extensions on the storefront, sandboxed checkout extensions and Shopify Functions at checkout. They give you visible, switchable control, and they keep our code inside the limits Shopify sets. It’s also why we keep so little data. A small team can’t promise to perfectly guard a large pile of sensitive data, but it can decline to collect it. Security isn’t a feature we finish. These positions are the test we apply to every change, and we publish them so you can hold us to them.How we run our apps
Our apps run on Cloudflare Workers, and their data is stored with Cloudflare, encrypted at rest. All traffic uses HTTPS, and production and staging use separate databases. Production secrets are kept in 1Password and supplied at deploy time. They never appear in source code, the storefront or the app admin. Every code change is reviewed, and automated checks scan each change for leaked secrets and vulnerable dependencies. Our internal tools sit behind a Cloudflare Access staff login, and every change made through them is logged. Staff accounts on every system that can reach your data use multi-factor authentication.If something goes wrong
Our incident response policy sets out how we contain an incident and when we notify you and Shopify. We notify any affected merchant without undue delay, saying what happened, what was affected and what you need to do. Live service status is at status.goodnative.co. To report a security concern, email support@goodnative.co.Bloom
What Bloom runs on your storefront
On the Online Store, Bloom runs only through a Shopify theme app extension: the Bloom app embed and the optional Bloom Product block. Both appear in Online Store → Themes → Customise, and switching the app embed off removes Bloom from your storefront.- Bloom never edits your theme files and doesn’t ask for permission to write to your theme. It reads your theme settings only to check that the app embed is on.
- Bloom uses no script tags, the legacy method Shopify is retiring.
- Bloom’s scripts are packaged in the extension and served by Shopify. Bloom’s loader only loads Bloom’s own files from that package, never an address taken from a setting.
- Design settings accept only known style properties with safe values. Bloom rejects any value that could break out of a style rule or load something from another server.
- Text fields are plain text. Messages that support formatting keep only basic formatting and safe links; scripts, frames, embedded objects and unsafe links are removed.
Checkout and payments
Bloom’s checkout and order status messages are Shopify checkout UI extensions. Shopify runs these in an isolated sandbox, away from the checkout page and its payment fields. Pre-order limits at checkout are enforced by a Shopify Function that checks the cart and returns a message if a limit is reached. Bloom doesn’t request any payment permission. It doesn’t handle card details, payment methods, transactions or payouts.Access to your store
Bloom asks only for the Shopify permissions its features use. You can see the full list in Settings → Apps → Bloom.
Bloom has no permission to change your theme files or payments.
Bloom’s access tokens for your store expire after an hour and are refreshed automatically.
Shopify requires all public apps to work this way from January 2027; Bloom already does.
Bloom is built to encrypt Shopify and Klaviyo credentials with AES-GCM, tying each encrypted credential to your store so it can’t be read as another store’s.
How Bloom checks requests
Requests from your Shopify admin carry Shopify’s signed session token. Requests from your Online Store come through Shopify’s app proxy, whose signature Bloom checks, and Bloom rejects any request more than 90 seconds old. Bloom checks Shopify’s signature on every webhook before reading it. On these requests, Bloom takes your store’s identity from the signature, never from anything the browser sends. A headless storefront identifies itself with a public storefront key in your page’s code. The key works only from the web addresses registered for it, requests that don’t say which site they come from can only read, and the key can be revoked. Every read and write is limited to the store the request belongs to.Shopper data
- Notify Me sign-ups go to your Klaviyo account and your Shopify customer records. Bloom holds a sign-up only while it delivers it.
- Storefront analytics record product interactions, not names or contact details. A random browser ID and cart reference are added only when the shopper allows analytics under your Shopify privacy settings.
- Bloom shares no shopper data with our own tools, such as our CRM.
- Bloom’s server error reports are set not to collect personal data, and emails and tokens are scrubbed before reports are sent.
Uninstalling Bloom
When you uninstall, Bloom deletes your store’s access credentials, sessions, Klaviyo connection and AI assistant connections straight away. Shopify asks Bloom 48 hours later to erase your store’s remaining data. If a deletion fails, Bloom tells Shopify, which sends the request again.Bloom and AI assistants
If you connect an AI assistant, a Shopify admin approves the connection inside Bloom, read-only is the default, and the connection expires after 30 days. The assistant never receives your Shopify access token, and every change it makes is recorded in Change History.Check Bloom yourself
- Everything Bloom can access is listed in Settings → Apps → Bloom.
- Bloom’s storefront code is a switch you control in the theme editor’s App embeds panel.
- Every settings change and who made it is in Bloom’s Change History.
- Each connected AI assistant, its access level and its last use are in Settings → Agent connections.
Glide
- Glide runs on your storefront only through the Glide app embed and never edits your theme files.
- It never records account, checkout or order pages.
- Glide stores no names, emails, addresses, customer IDs or order data. Without analytics consent, it sends no visitor ID and writes nothing to the shopper’s browser.
- Glide keeps its own storage, separate from Bloom’s.
- Sidekick and connected AI assistants can read Glide’s data but can’t change anything.