Commerce intelligence should earn access, not assume it.

Authentication

The frontend uses short-lived access tokens in memory and a refresh-session cookie to restore authenticated sessions. Unauthenticated application routes are gated rather than relying on a production development bypass.

Provider authorization

Merchants initiate OAuth or another supported authorization flow for accounts they control. Backend callbacks validate the authorization state before provider credentials are accepted. Connection and synchronization health is surfaced so a merchant can identify reauthorization or provider failures.

Minimum necessary access

Provider permissions should be requested only for features Metrico actually operates. Scope requirements are reviewed as integrations evolve, and provider write permissions are kept separate from read-only analysis wherever the provider model allows it.

Tenant and account boundaries

Authenticated workspace requests are expected to remain scoped to the selected merchant store and, where applicable, the selected advertising account. Provider identifiers supplied by a browser are not sufficient authority on their own; authorization checks must bind requested resources to the active merchant context.

Protected credentials

OAuth secrets, provider access tokens, signing secrets, encryption keys, and database credentials belong in protected server-side configuration. Public frontend configuration is reserved for values that are safe to expose to a browser.

Data integrity

Metrico is designed not to invent provider truth. Missing evidence should remain missing rather than being silently coerced into zero, source-specific attribution remains source-specific, and first-party behavior evidence remains descriptive observed behavior rather than causal proof.

Merchant-controlled actions

Metrico does not silently change advertising budgets or provider settings. When a feature can modify a provider, that capability must stay inside an explicit authorization and merchant-action boundary.

Operational safeguards

• Visible provider connection and synchronization state.
• Explicit reauthorization when provider access expires.
• Separation of Shopify commerce facts, attributed ad-platform outcomes, and first-party behavior.
• Loading, error, empty, and unavailable states rather than fabricated fallback values.
• Logging and operational diagnostics designed to avoid exposing credentials.
• Environment-specific secrets kept out of browser-delivered source.

Reporting a vulnerability

If you believe you found a security issue, follow the Responsible Disclosure process. A machine-readable security policy is also published at /.well-known/security.txt.