Cove Wishlist
Security
Last updated 2026-10-22
A wishlist app runs on every page of your store, so it is built to give an attacker as little to work with as possible.
No remote code
The code that runs on your storefront ships only inside the app’s theme extension, which Shopify versions on every deploy. Our servers never send scripts: the API returns data only, the wishlist pages served through your store are script-free Liquid, and your design settings are rendered by Shopify’s Liquid, not fetched by the browser. Changing what runs on your store therefore needs a new, recorded app version.
If a storefront feature ever misbehaves, we can switch the app’s storefront features off on a store at once. The switch is a setting the theme extension reads through Liquid, so pausing the app ships no code either; while it is off the app adds nothing to your pages.
Read-only access
The app holds only these permissions on your store. Its one write permission, write_app_proxy, lets Shopify send your store’s /apps/wishlist address to the app; it cannot change products, customers, orders or code.
| Permission | Why |
|---|---|
| read_orders | Count wishlist sales for your revenue report: which order lines came from a wishlist, and their amounts. Only order, line and product IDs and amounts are kept, never names, emails or addresses. |
| read_products | Show saved products and spot price drops and restocks. |
| read_customers | Tie wishlists to signed-in customers by their Shopify ID, and match imported lists to customers. |
| unauthenticated_read_product_listings | Show product details on the My wishlist account page. |
| write_app_proxy | Route your store’s /apps/wishlist address to the app. Can’t change store data or code. |
It never requests write_themes, write_script_tags, write_online_store_pages, write_products, write_customers, write_orders, read_all_orders. Without the first three it cannot edit your theme, add scripts or change your pages, so it cannot be used to change your store’s code. An automated test blocks any release that adds a permission.
Minimal data
We store Shopify IDs, not shoppers’ names, phone numbers or addresses, and only one kind of email address:
- Your store’s domain, plan, settings and the access token Shopify issues at install.
- For each wishlist: the Shopify customer ID (or, for a guest, a one-way hash of a random browser identifier), saved product and variant IDs, list names, any note a shopper adds to their own items, and share links they create.
- Daily counts for your analytics, never per-shopper histories.
- For wishlist revenue reporting, each order line that came from a wishlist: order, line and product IDs, quantity, amount and date, without the customer. Shopify sends the app only those order fields.
- Wishlist files you import, encrypted, for 24 hours at most; email addresses in them are never stored.
- The email a guest types into “Notify me when available”, for that alert only: encrypted with AES-256-GCM (bound to its own record, so a copied value can’t be opened elsewhere), never shown to you or exported, never written to a log, and deleted when the alert is sent, when the shopper unsubscribes, or after 180 days. Signed-in customers’ emails are read from Shopify when an alert goes out and never stored.
No third-party secrets (such as email platform API keys) are stored. See the privacy policy for retention periods.
How we run it
- Encryption in transit (HTTPS) and at rest.
- Hardware-key two-factor authentication on every account that can reach production.
- Production and test data kept apart; no shared logins.
- Access to production data is logged.
- Alert emails are sent from the EU (Lettermint, Netherlands), with no tracking pixels or rewritten links, a one-click unsubscribe in every email, and bounced or complained addresses blocked automatically.
- Every wishlist change is logged with internal IDs only, and an unusual volume of changes on a store raises an alert.
- Dependencies pinned, their registry signatures verified, and Shopify’s app security check run on every change; build tooling is pinned to exact versions.
Incident response
If we find or are told about a security incident, we:
- Contain it first: pause the affected feature or the app’s access, and revoke and rotate credentials.
- Tell affected merchants without undue delay, and within 72 hours of confirming it, what happened and what to do.
- Fix the cause and check every affected store.
- Publish a written postmortem.
Report a vulnerability
Email contact@stackcraftdigital.co.uk with what you found, how to reproduce it and the store or URL involved (a development store, please, not a live one). We reply within two business days, keep you updated until it is fixed, and will not take action against good-faith research that avoids harming merchants or shoppers, their data or the service. The same contact is published at /.well-known/security.txt.