Building a Secure
Shopify Label Designer
— Architecture, Drawbacks & Fixes

The system described in this article is a three-part platform: a Shopify storefront where customers browse and select products, a FabricJS Canvas Designer Tool where they customize label artwork, and a React Admin Panel where operators manage templates, SVG assets, safe zones, and bleed zones for each product.

The two architectural decisions that define this system's security posture are: hosting the designer tool on the same origin as the Shopify store, and embedding the admin panel inside Shopify Admin as an iframe. Both are reasonable, widely used patterns — but each one introduces a specific class of vulnerability that must be explicitly handled.

Decision 1 — Designer Tool on Same Origin

Hosting the designer at shopify-product.com/designer-tool is the simplest integration path. The active Shopify session cookie is automatically available, no OAuth redirect is needed, and the customer never notices they've moved to a different application. This is the "plug-and-play" approach.

It works because browsers automatically attach cookies to any request made to the same origin — including requests made from within the FabricJS canvas application when it calls your backend API. The customer is already authenticated with Shopify, so your backend can verify their identity without any additional login step.

Decision 2 — Admin Panel as Shopify Admin Iframe

Embedding the React Admin Panel inside Shopify Admin via an <iframe> with Content-Security-Policy: frame-ancestors restricting to the Shopify origin is a clean, well-supported pattern. Merchants see the admin panel as a native part of their Shopify experience, and you avoid building a separate authentication system for operators.

Shopify's App Bridge provides a postMessage-based communication channel between the parent Shopify Admin page and the embedded iframe, allowing the admin panel to receive context (store URL, access token) from the host.

Before examining what can go wrong, it's useful to understand the intended auth flow. The system involves three distinct authentication contexts that must never bleed into one another.

The critical step that most implementations skip: when the customer navigates to the designer tool, the backend should exchange the Shopify session for a purpose-built JWT — one that encodes { customerId, productId, designScope, exp: +30min }. All designer API calls use this JWT exclusively. The Shopify session cookie is never trusted by the design API.

// Token exchange endpoint — POST /designer/init
async function initDesignerSession(req, res) {
  // 1. Verify the incoming Shopify session
  const shopifyCustomer = await verifyShopifySession(req.cookies.session);

  // 2. Issue a scoped, short-lived JWT
  const token = jwt.sign({
    customerId: shopifyCustomer.id,
    productId:  req.body.productId,
    scope:      'design:write',
  }, process.env.JWT_SECRET, { expiresIn: '30m' });

  // 3. Mark handoff token as consumed (prevent replay)
  await db.handoffTokens.consume(req.body.handoffToken);

  res.json({ designerToken: token });
}

The following seven vulnerabilities are not theoretical — they are the direct, predictable consequence of the two architectural decisions described above when implemented without explicit mitigations. Each one is specific to this system's design.

window.addEventListener('message', (event) => {
  // Reject anything not from Shopify Admin
  const allowed = [
    'https://your-store.myshopify.com',
    'https://admin.shopify.com'
  ];
  if (!allowed.includes(event.origin)) return;

  // Also validate message structure before acting
  if (!event.data?.type || !event.data?.payload) return;

  handleAdminMessage(event.data);
});

// ❌ WRONG — authenticates but doesn't authorize
SELECT * FROM designs WHERE id = $1

// ✅ CORRECT — ownership enforced at query level
SELECT * FROM designs
WHERE id = $1
  AND owner_id = $2  -- $2 comes from the verified JWT, never from the request body

The fixes described above are not independent patches — they form a layered defense. Here is how they compose into a coherent architecture.

Layer 1 — Perimeter: Headers & CSP

Every response from your backend should include the following headers. These prevent the most common browser-level attacks before any application code runs.

# Required HTTP response headers for all routes
Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  connect-src 'self' https://api.shopify.com;
  img-src 'self' https://assets.cdn-yourbrand.com data:;
  frame-ancestors 'none';  # storefront pages — no framing

# Admin panel ONLY — override frame-ancestors
Content-Security-Policy:
  frame-ancestors https://your-store.myshopify.com https://admin.shopify.com;

X-Frame-Options: DENY           # legacy browser fallback for storefront
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin   # prevents token leakage in Referer header

Layer 2 — Authentication: Three Contexts, Three Tokens

The designer tool must never make API calls authenticated by the Shopify cookie. The admin panel must never make API calls authenticated by a customer JWT. The token exchange endpoint is the explicit boundary between these contexts — it is the most important endpoint in the entire system.

// Middleware stack for designer API routes
router.use('/api/design', [
  verifyBearerJWT,            // must be the scoped designer JWT
  requireScope('design:write'), // not just any valid JWT
  rateLimitByCustomer(100),   // 100 req/hour per customer
]);

// Middleware stack for admin API routes
router.use('/api/admin', [
  verifyShopifyAdminJWT,      // App Bridge session token
  requireRole('merchant'),   // not customer scope
  rateLimitByStore(500),      // 500 req/hour per store
]);

Layer 3 — Authorization: Ownership at the Data Layer

Authentication confirms identity. Authorization confirms permission. Every design operation must enforce ownership at the database query level — not in application code that might be bypassed. Use UUIDs as primary keys for all user-owned resources.

Layer 4 — Input: Sanitize at the Boundary

All user-supplied content — SVG files, FabricJS JSON, product IDs from query strings — must be sanitized and validated on the server before being stored or processed. Client-side validation is UX, not security. Never pass raw FabricJS JSON directly to a PDF renderer.

// SVG sanitization on upload
import createDOMPurify from 'isomorphic-dompurify';
import { JSDOM } from 'jsdom';

const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);

function sanitizeSVG(svgString) {
  return DOMPurify.sanitize(svgString, {
    USE_PROFILES: { svg: true, svgFilters: true },
    FORBID_TAGS: ['script', 'use'],
    FORBID_ATTR: ['href', 'xlink:href', 'src'],
  });
}

Before deploying, every item below should have a confirmed implementation owner and a test case in your security review.