Secure frontend, AI-safe backend: Webflow collections, fallback publishing and grants

A static site built from Webflow has no login, no session and no server deciding anything at request time. That makes it fast and hard to break, and it moves every security decision to two other places: the build, which decides what becomes public, and the runtime behind it, which decides what each caller may do. This article describes how the two pair up in the development patterns used across CRM Sync, PIM Sync and the client sites built on them, and why the pattern holds when AI writes much of the code and makes many of the calls.

This knowledge base is itself published both ways, from one set of Markdown files in GitHub:

• The CRM Sync book: every article in chapters, laid out like the Rust book (mdBook), with search and prev/next. Eleventy builds it from the Markdown on every push.
• The knowledge base on crm-sync.dev: the same articles on the Shopify storefront, published through the Webflow and GitHub pipeline.

It extends Same frontend, AI-secure backend, which covers the runtime half (the worker as the gate, Xano as the record). This article covers the publishing half, and the vocabulary for both.

1. Vocabulary

Memory safety is the guarantee that a program reads and writes only memory it owns, only within the bounds it was given, and only while that memory is still valid. A memory-safe language enforces this for every line, whoever wrote it: Rust at compile time, Python, Java and JavaScript at run time through a garbage collector and bounds checks. It is a property of the running software, not of its data, its network or its permissions.

Runtime and memory

Identity and permission

AI and publishing safety

2. Five layers, five different questions

Security controls are often compared as if they compete. They don't: each answers a different question, and a system can pass four and still leak through the fifth.

TLS and its limits are covered in depth in What TLS actually buys, and where it stops, and the difference from row-level encryption in Transport encryption and row-level encryption. The stack, and which layer may refuse gives each layer of the CRM Sync stack its single question.

The first three are largely handled by platforms. The logic layer is always yours, on any platform, and it is where most real breaches happen: an endpoint that returns another customer's order because it never checked ownership is perfectly encrypted and perfectly memory-safe. The publish layer is the one a static architecture adds. Anything the build emits is a grant to every reader, forever, so it needs the same discipline as an API response.

For how permission itself is modeled here (a scoped claim for one action, not a role for the whole building), see Permissions for AI, in plain terms.

3. Memory safety, in one section

Memory safety (defined in section 1) does not mean code can't be undone or rewound; Rust programs roll back transactions like any other. What it removes is three classes of bug:

• Use-after-free: using memory after handing it back, like reclaiming a coat with a ticket you already returned. Rust won't compile it.
• Buffer overflow: reading past the end of what you were given. Rust checks the bounds.
• Data race: two threads changing the same value at once without coordination. Rust's ownership rules forbid it.

Heartbleed (2014) is why this matters for TLS. OpenSSL, written in C, had a buffer over-read in its heartbeat feature: a request claiming a larger payload than it sent got back up to 64 KB of whatever sat in adjacent memory, including passwords, session cookies and private TLS keys. The encryption was sound; the code implementing it wasn't. TLS libraries written in Rust, such as rustls, rule that class of bug out in safe code.

What makes memory safety relevant to AI is that the compiler doesn't care who wrote the code. AI-generated Rust faces the same ownership checks as human Rust, and code that breaks them never ships. In C or C++ a plausible-looking AI-written overflow compiles and runs. Python gets its memory safety from its interpreter instead, as Render and Runtime: a working dictionary explains.

Where Rust actually runs in this estate: Shopify Functions accept Rust compiled to WebAssembly (see the October 1 brief), and the game11ty demo ships a no_std Rust GLB parser. The book above is laid out like the Rust book but built with Eleventy on Node.js, so it inherits no memory-safety guarantee from the resemblance.

4. Webflow as MVC

The sync that turns a Webflow site into static files is a model-view-controller split, and each seam is where a permission belongs.

Two rules keep the parts from leaking into each other. Markup travels; behavior never does: a Webflow page arrives as clean HTML, and everything interactive (login, consent, forms) comes from the repo's own components, as described in Fragments on Any Frontend. And each item has one writer: the ingest only manages items it created, so a Webflow-authored article and a Git-authored one share a collection without overwriting each other (Git to Every Surface).

Components follow the same split. A designer marks an element in Webflow (data-component="account", or the class component-account), and the sync swaps it for the repo's components/account.njk, passing only the element's data-* attributes, other classes and visible text as props. Webflow decides where; the repo decides what runs.

5. Fallback publishing: every fallback fails toward less exposure

A static pipeline needs fallbacks, because Webflow will always be partly unfinished: a template page not yet published, a locale not yet translated, a field not yet bound. The rule that makes fallbacks safe is that each one must publish less, never more.

The fallback that wasn't safe enough. The schema template rendered every rich-text field, on the reasoning that rich text is content and plain text is notes. One collection had a rich-text field named us_claim_note: an internal note about a regulatory claim. It was empty, so nothing had leaked, but the next note typed into it would have been published. The fix was a hand template that lists its public fields instead of excluding private ones. An allowlist fails closed when someone adds a field; a denylist fails open.

Review switches are publish grants. Legal pages carry a reviewed switch and product pages a claims_checked switch. Until a human (working with AI-assisted regulatory audits) turns it on, the page is published so reviewers can read it in place, but it is marked noindex, left out of the sitemap and given no structured data. Turning the switch on is the grant that lets search and answer engines quote it.

6. Pairing each seam with a grant

Every point where data crosses from one owner to another gets a named grant, enforced in a named place.

Three rules from elsewhere in the book make the runtime rows hold:

• The interface hides; the server enforces. A component may hide a button the caller's caps don't allow, but the worker refuses the call regardless. "A function reachable from front-end JavaScript is not a control; it's a suggestion" (Server-Side or It Didn't Happen).
• Authority is resolved per call, not at login. Scope, cap, expiry and consent state are checked before each effect (Server-Side Function Tools), and revocation is only as fast as that check (Paired permissions on machine endpoints).
• Identity is not authority. A signature proves who acted; only the grant proves they were allowed to (Two Ways to Give an Agent a Key).

Consent follows the same shape: deny everything synchronously before any tag exists, then replay the stored decision, then load tags into an already-correct state (Consent Resolution on Higher-Order Load).

7. The same seams in a Python backend

Xano gives you these controls through its interface. In a Python backend such as FastAPI, you bind them yourself, and the binding points are the same seams.

The row rule is the one most often missed:

@app.get("/orders/{order_id}", response_model=OrderPublic)
def get_order(order_id: int, user: User = Depends(get_current_user)):
    order = session.exec(
        select(Order).where(Order.id == order_id, Order.user_id == user.id)
    ).first()
    if not order:
        raise HTTPException(404)   # 404, not 403: don't confirm the record exists
    return order

Why the enforcement point sits in the backend rather than in database rules for this kind of runtime is covered in Why Xano + AI + e-commerce.

8. Why this is safe for AI-written code

AI changes two things at once: it writes more of the code, and it makes more of the calls. The pattern constrains both.

Build-time refusals constrain what AI builds. The content pipeline borrows the compiler's stance: when something disagrees, the build stops instead of guessing.

• The book's build stops if a document's front-matter category disagrees with the chapter it's listed under, and names the file.
• The FAQ pull refuses to write when Webflow holds 7 items and the repository holds 42, rather than deleting 35.
• The sync only ever rewrites the folders it generates; hand-written templates and components are never touched.

The rule that keeps these useful: never relax a refusal to make a build pass. A refusal an AI assistant can switch off is a suggestion, the same way a client-side check is.

Runtime identity constrains what AI does. An agent calls the same endpoints a person's app does, with a token. That token should carry only what the task needs, expire, and be checked on every call, as described in Permissions for AI Agents.

Neither replaces the other. Memory-safe code still serves the wrong customer's data if the ownership check is missing, and a perfect ownership check can still be bypassed by a memory bug like Heartbleed.

9. Checklist

Publishing

• Each collection with detail pages has a hand template that lists its public fields.
• No field is public because of its type alone; internal notes are named and kept out.
• Every review switch maps to noindex, sitemap exclusion and no JSON-LD until it's on.
• Each fallback publishes less than the step above it.
• Components get props from data-* attributes only, and no secret ever appears in Webflow.

Runtime

• Every per-user read is scoped to the caller's own rows, and a miss returns 404.
• The interface hides by caps; the worker enforces the same caps on every call.
• Agent tokens are scoped to one task, expire, and are checked per call.
• No tag loads before the consent decision is replayed.

Pipeline

• Disagreements stop the build with a named file; no refusal has an override flag.
• TLS, encryption at rest and memory safety are confirmed for each platform, and none is cited as covering the logic layer.

Sources

• The CRM Sync book, the Rust-book-style edition of this knowledge base.
• The CRM Sync knowledge base on the Shopify storefront, published through Webflow and GitHub.
• Permissions for AI, in plain terms · Entitlement Strategy · Server-Side Function Tools · Consent Resolution on Higher-Order Load · Fragments on Any Frontend
• Heartbleed: CVE-2014-0160. rustls: github.com/rustls/rustls.