TL;DR
Code Apps inherit valuable Power Platform controls, but they do not inherit complete application security. The platform manages identity, hosting and governed connector integration; the delivery team still owns the code, dependency choices, browser behaviour, authorisation assumptions, telemetry and secure release process.
Introduction
Power Apps Code Apps create an unusual security model. They are custom web applications, yet they run through a managed Power Platform host and can use platform connectors, solutions, sharing controls and Conditional Access.
That combination is a strength, but it can also create false confidence. Teams may assume that because an app runs in Power Platform, the platform has automatically secured everything inside it. It has not.
The more useful question is not “Are Code Apps secure?” but “Where does the managed platform boundary end, and what does the delivery team still own?”
First, be precise about the architecture
One misconception is worth clearing up early: Microsoft does not document Code Apps as Power Apps Component Framework applications. The official Code Apps architecture consists of your single-page application, the Power Apps client library, generated models and services, the configuration file and the Power Apps host.
The host manages end-user authentication and app loading. The client library exposes APIs and generated services that let the front-end perform data requests through Power Platform connectors. Your code remains the application layer.
That is the foundation of the shared-responsibility model. Power Platform manages important platform services, while the development team retains control over, and responsibility for, the custom front-end.
The Code Apps security responsibility model
| Security area | Power Platform provides | Delivery team still owns |
|---|---|---|
| Identity and app loading | Microsoft Entra authentication, Power Apps host and Conditional Access support | Do not build a second identity model in the front-end. Validate app sharing and access assumptions. |
| Connector integration | Generated connector models and services, consent experience and data-policy support | Choose connections carefully, use connection references for portability and verify target-system permissions. |
| Dataverse authorisation | Dataverse role-based security controls access to apps and data | Design least-privilege roles and avoid treating UI hiding as authorisation. |
| Outbound browser access | Environment-level Content Security Policy is available and enforced by default | Request only required destinations, review CSP reports and avoid broad allowlists. |
| Hosting | Compiled assets are hosted by Power Platform | Never embed secrets or sensitive data in the front-end bundle. |
| Monitoring | Health metrics and Power Platform Monitor are available | Add application telemetry and operational alerts for business-critical apps. |
| Release | Solutions and pipelines support controlled promotion | Own source review, testing, dependency checks and release approval. |
Identity is managed, but authorisation still needs design
Microsoft states that Code Apps support Microsoft Entra authentication and authorisation and Conditional Access. The host also exposes signed-in user context to the application.
However, authentication only proves who the user is. It does not prove that the user should see every record, invoke every action or access every connected system.
For Dataverse, security roles control access to apps and data. For other connectors, effective access depends on the connection and permissions in the target service. The front-end should never use visual hiding as a substitute for server-side authorisation.
Dataverse and connectors: Generated services are not a security shortcut
When a team adds Dataverse or another connector, Code Apps generate typed models and services that the front-end can import. Microsoft’s Dataverse guidance supports CRUD, paging, metadata and selected delegation scenarios through these generated services.
This is a clean development experience, but generated code does not remove the need to design permissions. It simply gives the application a managed way to call the data source.
For enterprise ALM, Microsoft recommends connection references rather than binding the app directly to a user-specific connection. This improves portability across development, test and production. It does not automatically create least privilege. The referenced connection and underlying service permissions still need review.
DLP and CSP solve different problems
Power Platform data policies govern connector use and help prevent unsafe combinations or blocked connectors. Microsoft also lists DLP enforcement during Code App launch as a supported managed-platform capability.
That is only one part of the outbound data story. Code Apps are browser applications, so Microsoft provides a separate Content Security Policy for Code Apps. The policy is configured at environment level and enforced by default. Notably, the default connect-src directive is 'none', which means external network destinations must be explicitly allowed.
The practical lesson is simple: do not treat DLP as the only control. Use data policies for connectors, CSP for browser destinations and code review for the application logic that decides what data is sent and why.
The front-end bundle is public, so secrets do not belong there
Microsoft’s system configuration guidance states that compiled Code App assets are hosted on a publicly accessible endpoint and that the endpoint does not currently support IP-based restrictions. Microsoft recommends Conditional Access for location-based access control.
This does not mean the app is open to unauthenticated users. It means the front-end assets should be treated like any other public web-client bundle.
Never embed secrets: Client secrets, API keys, passwords and private tokens do not belong in the bundle.
Do not package sensitive data: Retrieve protected information from a governed data source after authentication and authorisation.
Assume code can be inspected: Minification is not a security boundary.
Move privileged operations server-side: Use governed APIs, flows, Dataverse logic or an appropriate back end for operations that cannot safely run in the browser.
Custom code introduces conventional web risks
Code Apps provide freedom over the UI and logic. That same freedom means the delivery team must apply ordinary secure-development practices that a managed visual designer cannot apply on its behalf.
Input and output handling: Validate business inputs and render untrusted content safely.
Dependency governance: Review third-party packages, pin versions appropriately and include vulnerability checks in the engineering workflow.
Error handling: Avoid exposing sensitive implementation details through browser errors or logs.
Least privilege: Grant only the environment, Dataverse and connector permissions the app and its maintainers actually require.
Code review: Require peer review for security-relevant changes, not just functional approval.
These controls are not evidence that Code Apps are unsafe. They are evidence that Code Apps are software and should be treated with the discipline applied to other custom web products.
Monitoring needs two layers
Microsoft provides operational health metrics for Code Apps and supports Power Platform Monitor. For deeper application behaviour, Microsoft also documents Azure Application Insights integration.
The distinction is useful. Platform monitoring helps identify load and platform issues, while application telemetry can capture performance, network summaries and custom events after the app loads. Microsoft notes that startup failures remain visible through Monitor rather than Application Insights.
For business-critical apps, monitor both the platform and the product. A technically available app can still be operationally unhealthy if users experience slow journeys, repeated connector failures or silent business errors.
A production security checklist
Confirm the app is enabled only in approved environments.
Confirm the intended user population and Power Apps Premium licensing.
Use security groups and deliberate app sharing rather than broad convenience sharing.
Validate Dataverse roles and target-system permissions using least privilege.
Use connection references for solution portability where supported.
Review data policies for every connector used by the app.
Keep CSP enforced and allow only required network destinations.
Verify that no secrets or sensitive data are stored in the front-end bundle.
Require code review, test evidence and dependency checks before deployment.
Deploy through a solution and controlled pipeline, not direct production pushes.
Configure Power Platform monitoring and application telemetry.
Document incident ownership, rollback and support escalation before launch.
Final thoughts
Code Apps do not remove the security boundary. They shift it.
Power Platform takes on meaningful responsibilities: authentication, hosting, connectors, sharing, DLP support, Conditional Access and operational health. The delivery team takes on the security of the custom front-end, its dependencies, its data handling and its release quality.
That boundary is not a weakness. In fact, it is what makes Code Apps useful. But it only works when architects, Power Platform administrators and front-end developers understand which side of the boundary they own.
Before approving a Code App for production, use the responsibility model and checklist above to review both the platform controls and the software controls. For related guidance, read Stop giving developers System Administrator access just so they can deploy.
Frequently asked questions
Are Code Apps built on PCF?
Microsoft’s documented Code Apps architecture does not describe them as PCF applications. It describes a single-page application using the Power Apps client library, generated connector services and the Power Apps host.
Does Power Platform DLP protect every outbound web request?
Data policies govern connector use. Microsoft provides a separate environment-level Content Security Policy for Code Apps, with external network access controlled through the connect-src directive. Use both controls for their intended purpose.
Can secrets be stored in a Code App environment variable?
Do not expose secrets to the browser. Microsoft explicitly advises against storing sensitive user or organisational data in the app bundle. Privileged secrets should remain in a secure server-side service or managed secret store.
How should a Code App be monitored?
Use Power Platform health metrics and Monitor for platform-level behaviour, then add an application telemetry tool such as Application Insights when deeper product telemetry is required.
