Browse Guides

Move to another guide without going back to the documentation hub.

Protect Access Before Something Leaks

This page covers the handful of security checks that prevent the most expensive mistakes: weak account access, secret keys in frontend code, and untrusted domains calling your public API.

1

Protect the Account First

Most avoidable incidents start with weak account access. Protect the login first, because every other setting depends on who can open the workspace.

Complexity Requirements

  • Use a unique password for Sabdov
  • Use at least 8 characters
  • Choose a password different from the current one
  • Confirm the password change saves successfully before leaving the modal

Multi-Factor Auth

If multi-factor authentication is not available here, treat the account email as part of the security boundary and protect that inbox just as carefully.

2

Keep Public and Secret Keys Separate

Public keys belong to browser-side use

Public keys are for widgets, browser requests, and storefront-side use where Allowed Origins can still limit which domains may call them.

Secret keys stay on the server

Secret keys should live only in backend services, secure environment variables, or secret managers. They should never appear in theme code, client bundles, or public repositories.

Rotate quickly if a key is exposed

Sabdov shows generated keys only once. If a key is lost or exposed, revoke it and replace it instead of assuming it is still safe.

3

Limit Which Domains Can Use Your Public Key

Allowed Origins is the browser-side allowlist for your public key. If the domain is missing or mismatched, the request should fail instead of being accepted from the wrong site.

Origin Configuration
{
  "allowed_origins": [
    "https://*.myshop.com",
    "https://admin.myshop.com"
  ],
  "methods": ["GET", "POST", "OPTIONS"]
}

Wildcard support is limited to subdomains only. Prefer explicit production domains whenever possible, and never use "*" in production.

4

Treat Widget Output as Production Code

View Key

Review widget-related keys and delivery paths before you copy anything into the storefront.

Copy Snippets

Copy widget snippets only after you confirm the correct product, layout, and preview state. A copied snippet is now part of your live storefront.

Regenerate Only

Rotate keys when compromise is suspected, when access must be retired, or when you are replacing an exposed credential. Do not rotate casually on a live storefront.

5

If Something Looks Exposed or Blocked

Issue DescriptionRecommended Resolution
Authentication Failed

API requests return 401 Unauthorized even though the key seems correct.

Confirm you are using the right key type for the right environment, then check whether the key was recently regenerated or revoked.

Browser Request Blocked

A browser-side request fails because the domain is not trusted.

Verify that the exact domain is listed in Allowed Origins and that every production origin uses HTTPS with the correct subdomain.

Key Leaked in Public Repo

A secret key was accidentally committed to a public repository, theme file, or frontend build.

Revoke the exposed key immediately, replace it, review logs for misuse, and update every affected environment with the replacement.

Minimum security pass

Protect the account, separate public and secret keys, and review Allowed Origins before you publish code or hand credentials to anyone else.

Was this helpful?