Power Pages is different from the rest of the Power Platform in one crucial way: you’re building a website for the outside world. Anonymous visitors, customers, partners, and citizens will hit it and it’s backed by your Dataverse business data. That changes the priorities. With a canvas app behind your org’s sign-in, a mistake is contained. On a public Power Pages site, a misconfigured permission can expose real data to the entire internet.
The platform gives you enterprise-grade security, reliability, and scale out of the box. But security is a shared responsibility — Microsoft secures the platform; you are responsible for configuring your site correctly. These best practices focus on getting that part right.
1. Treat the authorization model as your most important work
This is where most Power Pages problems begin and end. Access to your data and pages is governed by three layers working together, and you need to understand all three:
- Web roles group users and act as the link between people and permissions. Every authenticated visitor automatically gets the Authenticated Users role; unauthenticated visitors fall under the Anonymous Users role. Create custom web roles for any access pattern beyond those defaults.
- Table permissions control access to the Dataverse data surfaced through lists, forms, Liquid, or the Web API. This is the gatekeeper for your business data.
- Page permissions protect individual pages and their components.
The rules that keep you safe:
Nothing is exposed until you grant it so grant deliberately. Configure table permissions for every table you surface, and assign them to the right web roles. Don’t assume data is private; confirm it.
Keep the Anonymous Users role on a tight leash. Anonymous means the whole internet. Give that role the absolute minimum it needs, and never attach sensitive tables to it.
Use column-level permissions for granular control. When a table holds a mix of public and sensitive fields, restrict at the column level rather than exposing the whole record.
Remember permissions are cumulative. A contact can hold multiple web roles and gets the combined access. Audit role assignments so nobody accidentally inherits more than intended.
2. Choose authentication that fits your audience
Power Pages supports a broad set of identity options through the Microsoft Identity Platform, using standard protocols (OpenID Connect, SAML 2.0, WS-Federation, OAuth 2.0). Match the provider to who’s signing in:
- Consumer / citizen-facing sites — use Microsoft Entra ID B2C or social providers (Microsoft, Google, Facebook, LinkedIn) so external users sign in with identities they already have.
- Partner or enterprise sites — bring your own identity provider (Entra ID, Okta, Auth0) via OIDC/SAML.
- On-premises integration — WS-Federation and SAML 2.0 connect to AD FS and similar services.
Wherever the data warrants it, turn on multifactor authentication and Conditional Access so access decisions factor in risk signals, not just a password. Each authenticated user maps to a Dataverse Contact record, which is what makes profile management and your authorization rules work design with that mapping in mind.
3. Enable the Web Application Firewall and think defense-in-depth
Every Power Pages site can sit behind a Web Application Firewall (WAF) that filters and blocks malicious requests. Turn it on. It applies rules to your HTTP traffic to defend against common attacks SQL injection, cross-site scripting, file inclusion, and misconfiguration and is a core part of protecting against the OWASP Top 10. Combined with the platform’s layered security stack, the WAF meaningfully lowers your breach risk for a few minutes of configuration.
4. Get your data architecture right
Each Power Pages site connects to exactly one Dataverse environment, which stores both your site’s metadata and its business data, encrypted in transit and at rest. A few habits pay off:
- Model your data with custom tables that cleanly represent what you collect from and share with your audience, rather than overloading standard tables.
- Keep the site-to-environment relationship clean don’t try to make one site serve unrelated data domains.
- Lean on Dataverse as the single source of truth, and connect to other systems through connectors only where you actually need them.
5. Design for scale and performance from the start
Power Pages can handle enormous, bursty traffic public sites have served thousands of requests per second during events like registrations and sales. But you should still build to take advantage of it:
- Use Azure CDN (a turnkey integration) to edge-cache static content. This is the single biggest performance lever for public sites and is essential if you expect traffic spikes.
- Keep lists and forms lean — surface only the columns and records a page needs rather than pulling large datasets.
- Cache where you can and avoid heavy, repeated server-side work on high-traffic pages.
The platform handles elastic scaling, fault tolerance, high availability, and regional failover for you but a bloated, uncached site will still feel slow no matter how well the infrastructure scales.
6. Build like a pro: source control and ALM
Power Pages isn’t just click-and-drag. Professional developers can manage site configuration as code:
- Use the Power Platform CLI to download and upload site configuration.
- Check that configuration into Git (GitHub or Azure Repos).
- Wire up CI/CD with GitHub Actions or Azure DevOps to deploy across environments.
- Promote through a proper dev → test → production path using solutions, rather than editing your live site.
This turns your website into a reviewable, versioned, repeatable deployment instead of a fragile one-off.
7. Integrate thoughtfully
Two integrations are common and worth doing carefully:
- Embedded Power BI — when you surface dashboards, configure row-level security so each visitor sees only their own data. Embedding a report without RLS on an external site is a data-exposure risk.
- Embedded chatbot (Copilot Studio) — adding an agent to a page is a great support experience, but scope its knowledge and authentication so it doesn’t surface anything a given visitor shouldn’t see.
8. Know what compliance and reliability you get and use it
Power Pages inherits Microsoft’s compliance coverage across global, regional, government, and industry standards, plus tools for data protection, data residency, GDPR, and EU Data Boundary requirements. If you operate under specific regulations, configure data location and the relevant controls deliberately rather than assuming defaults fit. On reliability, the platform already gives you geo-redundant primary/secondary deployments, automatic failover, and a shared-nothing architecture — you don’t build that, but you should understand it when you set expectations with stakeholders.
9. Test like an attacker before you launch
Before going live, browse your site as an anonymous user and as each web role to confirm people see exactly what they should — and nothing more. Try to reach restricted records directly through list filters, the Web API, and page URLs. The goal is to find the gap before a stranger does. Re-run this check every time you add a table or page.
Quick checklist
- [ ] Table permissions configured for every surfaced table and assigned to roles
- [ ] Anonymous Users role limited to the bare minimum
- [ ] Column-level permissions where records mix sensitive and public fields
- [ ] Web role assignments audited (cumulative access understood)
- [ ] Authentication provider matched to the audience; MFA / Conditional Access on where warranted
- [ ] Web Application Firewall enabled
- [ ] One clean site-to-Dataverse-environment mapping; sensible custom tables
- [ ] Azure CDN enabled; lists/forms trimmed; caching in place
- [ ] Site config in source control with a dev → test → prod pipeline
- [ ] Embedded Power BI uses row-level security
- [ ] Compliance/data-residency controls set for your regulations
- [ ] Tested as anonymous and every role before launch
Get the authorization model right, put a WAF in front, cache aggressively, and test as an outsider do those four things well and you’re ahead of most Power Pages sites on the internet.
This article draws on Microsoft’s Power Pages guidance documentation and the Power Pages Platform Capabilities and Architecture white paper by Dipti Jaiswal. For the latest details, refer to Microsoft Learn and the official Power Pages security and architecture white papers.