Power Platform security FAQs
Commonly asked questions about Power Platform security fall into two categories:
How Power Platform has been designed to help mitigate the top 10 Open Web Application Security Project® (OWASP) risks
Questions our customers ask
To make it easier for you to find the latest information, new questions are added at the end of this article.
OWASP top 10 risks: Mitigations in Power Platform
The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve software security. Through community-led open-source software projects, hundreds of chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.
The OWASP top 10 is a standard awareness document for developers and others who are interested in web application security. It represents a broad consensus about the most critical security risks to web applications. In this section, we'll discuss how Power Platform helps to mitigate these risks.
- The Power Platform security model is built on Least Privileged Access (LPA). LPA enables customers to build applications with more granular access control.
- Power Platform uses Azure Active Directory's (Azure AD) Microsoft Identity Platform for authorization of all API calls with the industry-standard OAuth 2.0 protocol.
- Dataverse, which provides the underlying data for Power Platform, has a rich security model that includes environment-level, role-based, and record- and field-level security.
Data in transit:
- Power Platform uses TLS to encrypt all HTTP-based network traffic. It uses other mechanisms to encrypt non-HTTP network traffic that contains customer or confidential data.
- Power Platform employs a hardened TLS configuration that enables HTTP Strict Transport Security (HSTS):
- TLS 1.2 or above
- ECDHE-based ciphers suites and NIST curves
- Strong keys
Data at rest:
- All customer data is encrypted before being written to non-volatile storage media.
Power Platform uses industry-standard best practices to prevent injection attacks, including:
- Using safe APIs with parameterized interfaces
- Applying the ever-evolving capabilities of front-end frameworks to sanitize input
- Sanitizing the output with server-side validation
- Using static analysis tools during build time
- Reviewing the Threat Model of every service every six months whether the code, design, or infrastructure has been updated or not
- Power Platform is built on a culture and methodology of secure design. Both culture and methodology are constantly reinforced through Microsoft's industry-leading Security Development Lifecycle (SDL) and Threat Modeling practices.
- The Threat Modeling review process ensures that threats are identified during the design phase, mitigated, and validated to make sure they've been mitigated.
- Threat Modeling also accounts for all changes to services that are already live through continuous regular reviews. Relying on the STRIDE model helps to address the most common issues with insecure design.
- Microsoft's SDL is equivalent to the OWASP Software Assurance Maturity Model (SAMM). Both are built on the premise that secure design is integral to web application security.
- "Default Deny" is one of the foundations of Power Platform design principles. With "Default Deny," customers need to review and opt in to new features and configurations.
- Any misconfigurations during build time are caught by integrated security analysis using Secure Development Tools.
- In addition, Power Platform undergoes Dynamic Analysis Security Testing (DAST) using an internal service that's built on OWASP Top 10 risks.
- Power Platform follows Microsoft's SDL practices to manage open-source and third-party components. These practices include maintaining complete inventory, performing security analyses, keeping the components up to date, and aligning the components with a tried and tested security incident response process.
- In rare cases, some applications may contain copies of outdated components because of external dependencies. However, after those dependencies have been addressed in accordance with the practices outlined earlier, the components are tracked and updated.
- Power Platform is built on and depends on Azure AD for identification and authentication.
- Azure AD helps Power Platform to enable secure features. These features include single sign-on, multi-factor authentication, and a single platform to engage with internal and external users more securely.
- With Power Platform's upcoming implementation of Azure AD Continuous Access Evaluation (CAE), user identification and authentication will be even more secure and reliable.
- Power Platform's Component Governance process enforces the secure configuration of package source files to maintain software integrity.
- The process ensures that only internally sourced packages are served to address substitution attack. Substitution attack, also known as dependency confusion, is a technique that can be used to poison the app-building process inside secure enterprise environments.
- All encrypted data has integrity protection applied before it's transmitted. All integrity protection metadata present for incoming encrypted data is validated.
Common security questions from customers
Following are some of the security questions our customers ask.
How does Power Platform help to protect against clickjacking?
Clickjacking uses embedded iframes, among other components, to hijack a user's interactions with a web page. It's a significant threat to sign-in pages in particular. Power Platform prevents the use of iframes on sign-in pages, significantly reducing the risk of clickjacking.
In addition, organizations can use Content Security Policy (CSP) to restrict embedding to trusted domains.
Does Power Platform support Content Security Policy?
Power Platform supports Content security policy (CSP) for model-driven apps. We do not support the following headers which are replaced by CSP:
How can we connect to SQL Server securely?
What ciphers are supported by Power Platform? What's the roadmap of continuously moving towards stronger ciphers?
All Microsoft services and products are configured to use the approved cipher suites, in the exact order directed by the Microsoft Crypto Board. For the full list and exact order, see the Power Platform documentation.
Information about deprecations of cipher suites is communicated through Power Platform's Important Changes documentation.
Why does Power Platform still support RSA-CBC ciphers (TLS_ECDHE_RSA_with AES_128_CBC_SHA256 (0xC027) and TLS_ECDHE_RSA_with_AES_256_CBC_SHA384 (0xC028)), which are considered weaker?
Microsoft weighs the relative risk and disruption to customer operations in choosing cipher suites to support. The RSA-CBC cipher suites haven't been broken yet. We've enabled them to ensure consistency across our services and products, and to support all customer configurations. However, they're at the bottom of the priority list.
We'll deprecate these ciphers at the right time, based on the Microsoft Crypto Board's continuous assessment.
How does Power Platform protect against Distributed Denial of Service (DDoS) attacks?
Does Power Platform detect jailbroken iOS devices and rooted Android devices to help with protecting organizational data?
We recommend you use Microsoft Intune. Intune is a mobile device management solution. It can help protect organizational data by requiring users and devices to meet certain requirements. For more information, see Intune's compliance policy settings.
Why are session cookies scoped to the parent domain?
Power Platform scopes session cookies to the parent domain to allow authentication across organizations. Subdomains aren't used as security boundaries. They also don't host customer content.
How can we set the application session to time out after, say, 15 minutes?
Power Platform uses Azure AD for identity and access management. It follows Azure AD's recommended session management configuration for an optimal user experience.
However, you can customize environments to have explicit session and/or activity timeouts. For more information, see User session and access management.
With Power Platform's upcoming implementation of Azure AD Continuous Access Evaluation, user identification and authentication will be even more secure and reliable.
The application allows the same user to access from more than one machine or browser at the same time. How can we prevent that?
Accessing the application from more than one device or browser at the same time is a convenience for users. Power Platform's upcoming implementation of Azure AD Continuous Access Evaluation will help to ensure that access is from authorized devices and browsers and is still valid.
Why do some Power Platform services expose server headers with verbose information?
Power Platform services have been working to remove unnecessary information in the server header. The goal is to balance the level of detail with the risk of exposing information that might weaken the overall security posture.
How do Log4j vulnerabilities impact Power Platform? What should customers do in this regard?
Microsoft has assessed that no Log4j vulnerabilities impact Power Platform. See our blog post on preventing, detecting, and hunting for exploitation of Log4j vulnerabilities.
How can we ensure there are no unauthorized transactions due to browser extensions or Unified Interface Client APIs allowing disabled controls to be enabled?
The Power Apps security model doesn't include the concept of disabled controls. Disabling controls is a UI enhancement. You shouldn't rely on disabled controls to provide security. Instead, use Dataverse controls such as field-level security to prevent unauthorized transactions.
Submit and view feedback for