Forum Discussion
Advocate IPower BI App Owns Data Embedding – Clarification on SameSite Cookie / CSRF Concern
Hi Nagaraj_D,
Thanks for reaching out to the Microsoft Fabric Community forum.
Additionally, the Power BI Security Whitepaper states:
Power BI embedded works using IFrame. An IFrame is not allowed to read or write data from the external web application or portal, and the communication with the IFrame is done by using the Power BI Client SDK using POST messages.
Reference:
Power BI security white paper - Power BI | Microsoft Learn
Generally Iframe is secure enough, if you still want additional security you can explore more on Azure private link.Microsoft also offers Azure Private Link for organizations that require additional network-level security. With Private Link, traffic between users and the Power BI service can travel through Microsoft's private backbone network instead of the public internet, providing enhanced network isolation and secure connectivity through private endpoints.
Some of the benefits include:
- Traffic remains on the Azure backbone network when accessing Power BI resources through private endpoints.
- Improved network isolation from public internet traffic.
- Support for secure connectivity scenarios involving on-premises environments when used together with technologies such as ExpressRoute or VPN connections.
For more details, see Private links for secure access to Fabric.
Power BI security white paper - Power BI | Microsoft Learn
About private Links for secure access to Fabric - Microsoft Fabric | Microsoft Learn
If you want to learn how to set up private link, please check this article:
Set up and use a tenant-level private link - Microsoft Fabric | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.Short answer: the SameSite finding on app.powerbi.com cookies is a false positive for your CSRF concern, and Front Door / App Gateway isn't needed to fix it.
In App-Owns-Data, access is granted by a short-lived embed token passed to the iframe via the Power BI Client SDK — not by those service cookies. Power BI's APIs use bearer tokens in the Authorization header, not cookies, so they can't be CSRF-forged and the browser won't auto-attach them. The captured cookies are Microsoft's own domain session cookies.
So the real surface is your app's token-generation endpoint: keep CSRF protection on your backend, SameSite+Secure+HttpOnly on your cookies, and Origin/Referer validation. That's the right focus and you've confirmed it's already handled.
Front Door / App Gateway are network/WAF layers; they don't change Microsoft's cookies or add CSRF protection you don't already have. Given per-client hostnames and added cost, I wouldn't add them just for this. Your existing architecture is sufficiently secure for the concern raised.
Super UserHi,
Yes, that is correct. In an “app owns data” embedding setup, the cookies for the `app.powerbi.com` domain are managed by Microsoft, so customers cannot control attributes like `SameSite`, `Secure`, or `HttpOnly` for those cookies.
The cookies you captured are Power BI service cookies, not application cookies from your custom app.
From your side, you should still secure your own application by:
- Using `SameSite`, `Secure`, and `HttpOnly` on your app cookies
- Implementing CSRF protection on your backend APIs
- Validating `Origin/Referer` headers where needed
For Power BI domain cookies specifically, only Microsoft can make configuration changes.
Hope this helps!!
Thanks!
Advocate IHi SamInogic ,
First, apologies for the delayed response. Also, thank you for the detailed explanation—it was very helpful.
After reviewing your feedback, I discussed the details with our web application backend team. They confirmed that "Application-owned cookies and security controls are handled separately within the application's managed infrastructure."
However, I still have a few questions and would appreciate your guidance:
- Since you mentioned that the cookies used by Power BI Services are managed and controlled by Microsoft, does that mean the embedded Power BI content is inherently protected against CSRF attacks from the Power BI side?
- I recently consulted with a security support team, and they suggested implementing additional protection using Azure Application Gateway and Azure Front Door. As I am relatively new to this security topic, I am trying to understand whether this approach is truly necessary for our scenario.
I am also concerned that the Azure-side solution may not be practical for our custom web application for the following reasons:
- Our application is hosted using client-specific hostnames, meaning each client has a different endpoint. Managing Azure Front Door configurations for every client could become complex.
- There would be additional infrastructure and operational costs.
- It introduces ongoing maintenance and monitoring overhead.
Our current architecture is:
Browser → Web Application → Power BI iFrame → Report/Dashboard
With Azure Front Door, the flow would become:
Browser → Azure Front Door → Web Application → Power BI iFrame → Report/Dashboard
Given that we are using the App-Owns-Data embedding model and following Microsoft's recommended security practices, is introducing Azure Front Door/Application Gateway really required from a security perspective, or would the existing architecture already be considered sufficiently secure?
I would appreciate any clarification or recommendations.
Thank you.
v-abhinavmuCommunity Support
Hi Nagaraj_D,
Thanks for reaching out to the Microsoft Fabric Community forum.
Additionally, the Power BI Security Whitepaper states:
Power BI embedded works using IFrame. An IFrame is not allowed to read or write data from the external web application or portal, and the communication with the IFrame is done by using the Power BI Client SDK using POST messages.
Reference:
Power BI security white paper - Power BI | Microsoft Learn
Generally Iframe is secure enough, if you still want additional security you can explore more on Azure private link.Microsoft also offers Azure Private Link for organizations that require additional network-level security. With Private Link, traffic between users and the Power BI service can travel through Microsoft's private backbone network instead of the public internet, providing enhanced network isolation and secure connectivity through private endpoints.
Some of the benefits include:
- Traffic remains on the Azure backbone network when accessing Power BI resources through private endpoints.
- Improved network isolation from public internet traffic.
- Support for secure connectivity scenarios involving on-premises environments when used together with technologies such as ExpressRoute or VPN connections.
For more details, see Private links for secure access to Fabric.
Power BI security white paper - Power BI | Microsoft Learn
About private Links for secure access to Fabric - Microsoft Fabric | Microsoft Learn
If you want to learn how to set up private link, please check this article:
Set up and use a tenant-level private link - Microsoft Fabric | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.