Power Pages Security Audit
A Power Pages site is one table permission away from publishing your Dataverse to the internet.
Power Pages puts Dataverse on the public internet, and the only thing standing between a record and an anonymous visitor is a table permission attached to a web role. Get that wrong and the data is not hidden behind an obscure URL: it is reachable through lists, forms, Liquid and the Web API, by anyone who asks. We audit your site against Microsoft's own security model, show you which records an anonymous visitor can reach today, and give you a prioritised plan to close the gaps.
What a Power Pages security audit covers
Power Pages security is not obvious. Access is granted, not withheld: a table permission with Global access reaches every record in the table, and if it is attached to the Anonymous Users web role, that means everyone on the internet. Web roles are cumulative, so a person holds the sum of every role assigned to them. The same permission governs lists, forms, Liquid templates and the Web API at once, so a field hidden on a form can still be read through the API. Sites are often built by a maker under delivery pressure, go live, and are never reviewed again.
We audit the site the way an attacker would read it, then the way an administrator has to fix it. Every table permission is mapped to its access type, its privileges and the web roles it is attached to, so you can see which records are reachable anonymously and which are reachable by any authenticated user. We check column permissions, page permissions, site visibility, the authentication providers in use, CORS and HTTP headers, and whether the Web API returns more than the pages show. You get findings rated by severity, a remediation plan, and evidence you can hand to an assessor.
Table permission and web role mapping
Every table permission mapped to its access type, its privileges and the web roles it is attached to, so the reachable data set is visible rather than assumed.
- Global, Contact, Account, Self and Custom access types reviewed per permission
- Anonymous Users and Authenticated Users exposure listed explicitly
- Parent and child permission chains followed to their effective result
- Permissions with no web role, and roles with no permission, identified
Web API and Liquid exposure
Table permissions govern lists, forms, Liquid and the Web API together. We test what the API actually returns, not what the page chooses to display.
- Web API responses compared against the configured table permissions
- Columns readable through the API but hidden on the form
- Liquid templates that query Dataverse outside a permission boundary
- Related records reachable through lookups and relationships
Column permissions, pages and site visibility
The controls that sit beside table permissions, and the ones most often left at their defaults.
- Column permission profiles on sensitive fields
- Page permissions on pages assumed to be private
- Site visibility, and whether a pre-production site is publicly reachable
- Authentication providers, and local versus Entra External ID configuration
Platform hardening and evidence
Microsoft's own scanning and firewall capabilities applied, and the output written up so it can be handed to an assessor.
- Power Pages security scan run and its findings triaged
- CORS and HTTP header site settings reviewed
- Web application firewall options, native and via Azure Front Door
- Findings rated by severity with a remediation plan against each
What you get from the audit
You can see what is actually reachable
Effective access, mapped
One view of which records an anonymous visitor and an authenticated user can read, write and delete today.
The gaps are ranked, not just listed
Prioritised remediation
Findings are rated by severity, so the permission exposing personal information is fixed before the missing header.
Evidence an assessor will accept
Assessment-ready report
A written report of scope, method, findings and remediation, suitable for a security review or an assessment pack.
Who needs a Power Pages security review
Built for:
- CISOs and security teams who have inherited a public-facing Power Pages site
- Government agencies publishing services built on Power Pages
- Platform owners preparing a site for a penetration test or an assessment
- Organisations that built a portal quickly and never reviewed it
- Teams migrating from Power Apps portals to Power Pages
Runs on
- Microsoft Power Pages
- Power Pages Security workspace
- Power Pages security scan
- Portal Management app
- Microsoft Dataverse
- Power Platform admin center
Built to align with
- Designed for IRAP PROTECTED environments
- Australian Privacy Principles
- Essential Eight aligned
Accelerate Your Desired Outcomes
Clients choose us because we:
- Are certified Microsoft experts.
- Take a holistic approach to understand your business needs and bridge the gaps with the right tools and solutions.
- Collaborate with you and prioritise your input to ensure a client-centric approach.
- Operate with agility and speed, thanks to our small teams and 2-week sprint model.
- Start developing on day 1 to get results quickly.
- Focus on delivering outcomes, not just scope, to ensure we meet your goals.
- Offer cost-effective solutions that enable you to reach your goals faster.
- Stay flexible and open to new and better ways of doing things to continually improve your business processes.
- Are proudly Australian owned and operated.
Frequently asked questions
What are the main security controls in Power Pages?
- Microsoft's security model for Power Pages has seven parts: site visibility, authenticated users, web roles, table permissions, page permissions, HTTP headers, and the security scan. Table permissions are the one that matters most, because they control access to Dataverse records through lists, forms, Liquid and the Web API at the same time. A site can also sit behind a web application firewall, either the native Power Pages capability or Azure Front Door.
What is the most common Power Pages security mistake?
- A table permission with Global access attached to the Anonymous Users web role. Global access applies the permission to every record in the table, and the Anonymous Users role covers everyone on the internet. It usually happens during build, when a list or form will not render and the quickest fix is to widen the permission. The site works, the deadline is met, and the permission is never narrowed again.
Can someone read data through the Web API that is hidden on the page?
- Yes, and this is the finding people find hardest to believe. Table permissions govern lists, forms, Liquid and the Web API together, but hiding a column on a form is a choice made in the form, not a permission. If the table permission grants read on the record, the Web API returns the columns that permission allows, whatever the page displays. Column permission profiles are the control that actually restricts a field.
Does the built-in Power Pages security scan find everything?
- No, and it does not claim to. The security scan checks for common web threats such as cross-site scripting and insecure libraries, and it is worth running. It does not reason about your data model, so it cannot tell you that Global access on a table of applicants is wrong for your organisation. The scan finds web vulnerabilities; a permission review finds data exposure. An audit needs both.
We are moving from Power Apps portals to Power Pages. Does that change our security?
- The underlying model is the same: web roles, table permissions, page permissions. What changes is where the configuration lives and how much of it a maker can see. The design studio Security workspace surfaces table permissions that previously lived only in the Portal Management app, while some settings, such as the Parent access type, are still configured there. A migration is a good moment to audit, because permissions carried across from a portal built years ago are rarely questioned.
Do we still need a penetration test?
- They answer different questions. A penetration test probes the running site from the outside. An audit reads the configuration from the inside, which is where data exposure actually lives, and an outside-in test will not reliably find a Global table permission unless the tester happens to guess the right API query. Organisations that need real assurance usually do both, and doing the audit first makes the penetration test more useful.
Proof and further reading
Choose Accelerate and experience a more efficient, faster, and cost-effective way to achieve your business goals.
Talk to a specialist