Secure Power Pages by checking permissions and Web API gates
Diesen Beitrag auf Deutsch lesen
Review anonymous table permissions, Web API settings and custom web roles to prevent accidental Dataverse exposure through Power Pages.
TL;DR
Power Pages data access depends on web roles and table permissions, while the Web API also requires enabled table settings and an explicit fields list. A Global Read permission for Anonymous Users combined with Webapi/contact/enabled set to true and Webapi/contact/fields set to * can expose contact records without sign-in.
Original by Nick Doelman, on The ReadyXRM Blog. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Admins/CoE: Review every table permission assigned to Anonymous Users, every Global access grant, and each Web API enabled table; remove unjustified public access because permissions combine and the broadest grant wins.
- Security/Compliance: Replace Web API fields wildcards with explicit columns, disable unused tables, and treat every listed column as published data; this limits accidental exposure of personal or commercially sensitive information.
- Makers: Keep Authenticated Users Role set to No on custom web roles and use assigned contact membership; setting Yes grants the role to every signed-in user.
Frequently asked questions
Which two gates must a Power Pages Web API request pass?
The first gate is the site settings per table: Webapi/contact/enabled must be true, since the default is False, and the matching fields setting needs an explicit column list.
Why is a wildcard in the Web API fields setting dangerous in Power Pages?
An asterisk in the fields setting publishes every column of that table.
What is risky about the Authenticated Users Role flag on custom web roles?
When it is set to Yes, the custom role becomes the default role for every authenticated user, whether you assigned the user to it or not.