CRM Sync — Security Audit & Paired Data Requirements

Date: 2026-05-18 Version: 1.1 Worker Version: dac8f178-f6ed-4a11-96be-f640a67c64ae

1. Security Audit Summary

1.1 Route Auth Coverage (Post-Hardening)

All 67 routes verified. Every write endpoint and admin endpoint now requires authentication. Per-tenant admin keys provide granular access control with platform key fallback.

Auth Layers

Complete Route Matrix

Notes

• /auth/consent-sync (#32): Called from client-side embed scripts with user_id in body. The handler writes to Xano consent_records. This endpoint accepts unauthenticated requests from the embed context — consent changes from the cookie banner and compliance page arrive here. This is by design (the embed runs before the user has a JWT session), but the endpoint should be hardened with rate limiting.
• GET /config (#3): Returns config with all secrets masked (first 4 + last 4 chars). No auth required for read, but secrets are never exposed.
• Embeds (#7-10): Public HTML endpoints. Secrets are stripped via getPublicCrmConfig() before injection.

1.2 Fixes Applied (2026-05-17)

2. Paired Data Requirements

2.1 System Pairs — CRM Sync (Webflow-Primary Gateway)

CRM Sync uses Webflow as its primary headless gateway and Shopify as the commerce data source. Data flows bidirectionally between 7 systems.

Webflow (Gateway) ←→ Worker ←→ Shopify (Commerce)
                       ↕
              Xano (Source of Truth)
                       ↕
              GA4 / Adobe AEP / Resend

2.2 Data Pair Matrix

Each pair defines: what data crosses the boundary, which direction, what trigger, and what security contract.

Thesis — keep the castle and the moat; distribute the gold. The incumbent's mistake is not having walls — it is hoarding all the gold in one vault behind them. That vault is the blast radius: one breach takes everything, and the hoarding also locks the value away from the people who need it. This architecture keeps the castle and the moat — Cloudflare's WAF, DDoS, and edge governance still stand — but spreads the gold across many pockets: PCI in Shopify, PII/consent in Xano, a draft mirror in Webflow, grants that verify with a public key. The result is **security and accessibility in the same move** — nothing concentrated to steal, everything reachable to those authorized:

• The walls stand, but they hoard nothing. Being inside the perimeter grants nothing — every request is re-verified per-action (403 without the right consent/mandate). The castle governs access; it does not store the treasure.
• No single vault. The gold sits in many pockets — Shopify (PCI), Xano (PII/consent), a draft Webflow mirror. Breach one and you get a fragment, never the hoard.
• No secret to steal. Entitlement grants are offline-verifiable with a public key — the proof of trust is not a secret an attacker can exfiltrate.
• No single point to take down. Three legs, self-healing — the loss of any one leg is a Tuesday, not a breach.
• Distributed = usable. Because the gold is spread out for people and agents to use (consent-gated), distribution is the accessibility model — not a vault to petition, a network to reach.

"Zero Trust" is simply the admission that a hoarded, trusted vault is how you get breached.

Substrate ≠ Security. Webflow and Xano are where this runs — not what makes it safe. The controls live in the architecture below: HMAC-SHA256 mandates, PKCE + OIDC auth, JWT sessions, per-action authorization, offline-verifiable Ed25519 grants, real-time consent. These are the same cryptographic primitives enterprise systems use — and the agentic model (A2A read vs AP2 spend, per-action gating, revocable consent) is one most enterprise CRMs do not have at all. No-code substrate; enterprise-grade boundary logic. Judge the boundary logic, not the vendor logos.

Closed-boundary software and AI governance. A closed, monolithic, single-vendor boundary governs by containment — a fixed perimeter, a fixed release cadence, a policy engine you cannot reach into. For human-speed CRM that is tolerable. For governing an autonomous, real-time AI actor it is a liability, because AI incidents move faster than a closed system can respond. A closed boundary denies the three capabilities AI governance requires:

• It cannot heal. When state drifts or a record corrupts, a closed system waits for the vendor's next sync, patch, or support ticket — while an agent compounds the error on stale data. Self-healing (idempotent reconcile; the mirror that rebuilds itself from the system of record) is the only thing that keeps an autonomous actor off bad data.
• It cannot fall back. A monolith degrades to off: if its one plane is down, governance stops — and the agents either halt (lost commerce) or, worse, proceed ungoverned (a control gap is an incident). Graceful degradation (authorize offline, capture online, buffer-and-replay across three legs) keeps the guardrails on even when a leg is down. Governance must fail closed and keep working.
• It cannot forward-deploy. When an incident needs a rule changed now — revoke a mandate, tighten a scope, block a rail — a closed boundary makes you file a change request and wait for a release window. An edge-deployed, code-owned governance layer pushes the new rule to every request in seconds. AI incident remediation is measured in seconds, not sprints.
• It taxes your success. A closed boundary bills you to move your own data — egress fees that scale with volume. The better your AI performs, the more it queries and moves, the higher the bill: you are taxed precisely as AI adoption succeeds. Governance you own, at the edge, moves data without a toll booth — so the economics improve as you scale instead of punishing it.

Implication: you cannot govern an autonomous, real-time actor with a system that changes only on the vendor's schedule, recovers only on the vendor's timeline, works only when every component is up, and charges you more the more the AI works. AI governance requires a layer you can heal, fall back, forward-deploy, and scale — without a toll booth — at the speed the AI operates, which a closed boundary, by definition, forbids. This is the "Risk Management for AI Incident Remediation" framework the architecture names.

Layer model (canonical: the published architecture at <https://crm-sync.webflow.io>). Five layers, each with a distinct job; no single one is a hard dependency — the three-leg design degrades gracefully if any is unavailable:

1. Cloudflare — edge governance (the "God layer"). Edge OTP + admin-only gating, WAF, DDoS protection, bot mitigation, secrets, rate limits. Governs security for every request — but is not a single point of failure: entitlement grants are offline-verifiable (Ed25519 public key), writes buffer and replay, and the PWA serves cached reads.
2. Authentication Layer. Google (OAuth + PKCE), Shopify (OIDC + PKCE), Email/Password (Xano direct).
3. Verification Layer — Xano. Find-or-create users; the system of record for identity, PII, and consent state.
4. Token. Worker-issued JWT (7-day TTL) — the scoped session / mandate credential.
5. Data Layer. Webflow (Collection Sync + Entitlement — the draft-only CRM mirror, Pair 2), Shopify (metaobjects, tags, A2A/AP2 JSON — the PCI plane: cardholder data stays in Shopify's PCI scope), GA4 + Adobe/BAU (user props, UCP conversions).

Plane separation: payment/cardholder data stays in Shopify's PCI scope; identity / PII / consent are the Xano system of record; Webflow holds a draft-only CRM read-model mirror (no PCI, no Webflow commerce); Cloudflare governs but is not depended upon.

Pair 1: Shopify ↔ Xano (Customer Identity)

Security: HMAC-SHA256 on webhooks. Admin token (shpua_) for GraphQL. Token auto-refreshed before 60-min expiry.

Pair 2: Xano → Webflow (Customers CRM mirror — resilience leg)

The Webflow "Customers" collection is a read-model CRM mirror / backup of Shopify customer profiles — the same role Salesforce or HubSpot play (contact PII, consent state, and commerce aggregates for CRM use). It is one leg of the three-leg resilience design (Shopify ↔ Xano ↔ Webflow): if one leg is unavailable, the customer read-model still exists in the others. Mirror items are written as drafts — a back-office copy, not published to the live public site.

Plane separation (why this is a CRM mirror, not a PCI / commerce exposure):

• Shopify = PCI plane — cardholder / payment data never leaves Shopify's PCI-compliant scope. We never store, mirror, or transmit card data.
• Xano = PII / identity / consent — the system of record.
• Webflow = CRM mirror + presentation — the profile read-model only, draft-only. Webflow's native E-commerce is NOT used (no products, checkout, orders, or payment data).

Security: Webflow CMS token (write-scoped, worker-held). Mirror items are drafts (off the live site). No PCI / cardholder data is ever mirrored — payment data stays in Shopify's PCI plane. The mirror performs no transactional or commerce function; it is a CRM read-model backup, comparable to a Salesforce/HubSpot contact sync.

Pair 3: Xano ↔ GA4 (Analytics Events)

Security: GA4 API Secret stored in KV config. No PII sent — only tag categories and consent state. Client ID format: crm-sync.{userId}.

Pair 4: Xano ↔ Adobe AEP (CDP Streaming)

Security: Adobe IMS OAuth (client_credentials). PII hashed with SHA-256 via Web Crypto API before transmission. Raw PII never leaves the worker. IMS tokens cached in KV with TTL.

Pair 5: Xano ↔ Resend (Transactional Email)

Security: Resend API key stored as wrangler secret. Reset tokens are KV-stored with TTL, single-use.

Pair 6: Worker ↔ Cloudflare KV (Config & State)

Security: KV encrypted at rest (Cloudflare managed). Secrets masked in GET /config. Short TTLs on auth state.

2.3 Baseline Data Contract

Every data pair has the following contract:

1. Identity resolution — Email is the primary key across all systems (Shopify GID for Shopify-specific operations)
2. Source of truth — Xano is canonical. Conflicts resolved by most-recent-write-wins.
3. PII boundary — Raw PII stays within Worker + Xano + Shopify + Webflow CMS + Resend. GA4 and Adobe AEP receive hashed or categorized data only.
4. Auth boundary — Every cross-system call uses the target system's native auth (Shopify Admin token, Webflow CMS token, Xano API key, GA4 API secret, Adobe IMS OAuth, Resend API key).
5. Tenant isolation — Config and credentials are scoped to tenant:{shop}:config. No cross-tenant reads.
6. Audit trail — All consent mutations logged to consent_records (append-only). Adobe sync logged to adobe_sync_log.

3. Remaining Hardening Items