The partner REST service that shipped without authentication

Problems

1. No authentication on a service that returns all orders - anyone who learns the URL reads the whole customer base.
2. Apply entity access is off, so the Customer access rule with its XPath is bypassed entirely by the microflow.
3. The retrieve has no XPath constraint of its own, so even with entity access on, the service is not scoped to a partner.
4. The integration reuses a module role meant for humans instead of its own role.

Required configuration

• Create a dedicated module role (e.g. PartnerIntegration) with read access only to the entities the partner needs, and a dedicated entity or constant holding partner credentials.
• Authenticate with basic authentication against a partner entity, or a custom authentication microflow; do not use No authentication outside a throwaway local test.
• Turn Apply entity access on for the microflow, and add an explicit XPath constraint (partner id, order status, date window) so the service cannot return more than the contract allows.
• Review the published service operation by operation: HTTP method, path parameters, response mapping, and what happens on an empty result.

Before production Test with a real partner credential, not only an administrator, and confirm that requesting another partner's order id returns nothing rather than a 403 with data.

Why the access rule does not help

• Entity access XPath constraints protect retrieves of that entity when the platform applies them (pages, and microflows with Apply entity access on). Here the dashboard microflow retrieves Orders with entity access off, and the result is written into a non-persistent Overview entity.
• Access rules on a non-persistent entity control which members a role may see; they cannot express a row-level XPath constraint, and they say nothing about how the numbers were computed. The Overview object is a legitimate object with legitimate members; the leak happened upstream.

Fix

• Constrain the retrieve itself: count and top-five must run on the same XPath the customer is entitled to, e.g. [Order_Customer = '[%CurrentUser%]']. Reusing one constrained retrieve for both numbers is safer than two ad-hoc ones.
• Prefer turning Apply entity access on and letting the existing access rule do the filtering, so a future dashboard cannot forget the constraint.
• Check the aggregate path too: an Aggregate list operation over an unfiltered retrieve returns a system-wide sum just as easily as a count.

Verification Log in as two different customers and confirm the totals differ and match their own orders.

Checklist

• Demo users are off, and no page or microflow is left without a module role.
• Every entity has access rules for every role that can reach it, with member-level write restrictions where the UI does not need to write.
• Microflows and nanoflows that do privileged work are restricted to the roles that should run them, not to Administrator as a shortcut.
• Constants for integration endpoints and credentials are configured per environment; no production secret sits in the model.
• The published REST services and any consumed endpoints are reviewed as an inventory, including the ones built for a demo.

Most often skipped The negative test: signing in as the least privileged role and trying to reach data by URL, by a bookmark to a page, or by calling the REST endpoint directly. Teams test that the intended user sees the intended data and rarely test that an unintended user sees nothing.

Also check the scheduled events and event handlers that run with system rights; these bypass user context and are a common way restricted data reaches a page indirectly.