Every portal raises the same question: this site is on the public internet and it renders business data — what exactly stops it from serving the wrong thing? The xMatix answer is a scoping model with three load-bearing rules, each enforced by the platform rather than by authoring discipline. Understanding them is what turns "is our portal safe?" from a feeling into a checklist.
The three rules
Demo2 currently has no portal row, so the exact General, Pages and Data Views security gates cannot be captured without creating production configuration. This page therefore stays text-led rather than reusing the empty registry as evidence for controls it does not show. In a configured tenant, Active controls whether the site can serve at all, Anonymous visitors decides whether the tenant's anonymous principal may enter, and the signup switches create identities without widening a page or data view's audience.
- Only published content is served. Page drafts, unpublished pages, site settings, unpublished or deactivated sites — none of it ever reaches a visitor. What serves is the published snapshot of each page and nothing else.
- Authored pages query records only through published data views. The authored-content surface resolves the site, fetches a published page, queries a published data view and accepts signup; it has no route to the platform's general data interfaces. A commerce portal may additionally call a separately allowlisted storefront surface for catalog, cart, checkout, payment and customer-account workflows. Those operations do not turn a page design into an unrestricted data client.
- Every read executes as a real identity. Anonymous reads run as the portal's visitor identity; authenticated "my records" reads run as the signed-in external user. Either way, the standard security engine — entity permissions, record-level security, field-level security — makes the decision. The portal adds no authorization logic of its own, which means there is no second rulebook to drift out of sync.
The anonymous identity and its profile
Each organization has one synthetic anonymous visitor principal shared by all of its portals. Public requests execute as that external, non-sign-in account, and each portal record points to it so the serving identity remains inspectable. The principal carries the least-privilege Portal Anonymous security profile, and publishing is what feeds that profile: publishing a public data view grants read access on that entity, and the grant is revoked automatically when the last active public view of the entity — across all of your portals — is removed or deactivated.
Because both the principal and profile are tenant-wide, one warning matters: any access you grant the profile by hand applies to every anonymous visitor on every portal in the organization, and manual grants survive the automatic revocation (which only withdraws what publishing added). Treat widening that profile as publishing — do it only when you mean "public".
How it composes with your organization's security
A row reaches a visitor only by passing every layer, from the outside in:
- Site gates — the site is active, published, and (for anonymous visitors) allows anonymous access.
- Page gates — the page is active, published, and its audience admits the caller.
- Data view gates — the view is active, its audience admits the caller, and its page size cap bounds the volume.
- The view definition — the entity view's columns and base filter shape what the query even asks for.
- The security engine — entity permissions, record-level rules and field-level security apply to the executing identity, exactly as they would inside the application.
For signed-in visitors the last layer is where "my records" comes from: external users' record access defaults to private, so an authenticated view shows a person only the records they own or are linked to, unless your rules deliberately share more. See Record-level security and sharing.
What never leaves the platform
- Page drafts — the portal serves only published snapshots.
- The site's settings document.
- Entities without a published data view.
- Records and fields the executing identity cannot read.
Published page layouts and data views are read-only. Signup deliberately creates identity records, and a portal bound to a commerce channel may also create or update the narrowly scoped records required by cart, checkout, payment and account workflows. Those writes go through their purpose-built storefront controllers and checks; there is still no general record-write endpoint available to an authored page.
Common questions
Is everything in a published data view public?
For a Public view, plan on yes: its rows and columns are served to anyone, identically, by design. The security engine still applies — field-level rules can hide columns, record rules can exclude rows — but the sound practice is not to rely on that as the fence. Publish a public view only when everything its filter matches is fine to treat as public information.
Can portal visitors change data?
Not through a page layout or published data view: both are read-only, and an Authenticated view changes who executes the read rather than granting a write. Signup does create the visitor identity, and commerce portals can write through their explicit cart, checkout, payment and account workflows. If a requirement needs arbitrary record editing, do not infer it from portal sign-in or a data view; that capability is not exposed by the authored portal layer.
We deleted a data view — is the entity still exposed?
Only if another active public view of the same entity exists on any of your portals; the automatic read grant is withdrawn when the last one goes. The Data Views tabs across your portals are the complete list of general record-query exposure from authored pages. Purpose-built commerce operations have their own configured catalog and transaction boundaries and must be reviewed separately.
Does the Portal Anonymous profile show up in our security administration?
Yes — it is a normal security profile, visible alongside your others, and that is intentional: portal exposure is auditable exactly where you already audit access. Its publish-managed grants come and go with your data views; anything extra you see on it was added by an administrator and deserves the "is this meant to be public?" question.