Forum Discussion
Advocate IPower BI App Owns Data Embedding – Clarification on SameSite Cookie / CSRF Concern
Hi Folks,
In my organization, we are using the Power BI "app owns data" embedding solution to embed Power BI reports, dashboards, and paginated reports into a custom web application, so users can access them without needing a Power BI Pro license.
Our security team identified a potential issue related to CSRF attacks that could lead to account takeover or unauthorized data access. Specifically, they observed Power BI-related request URLs/cookies without the SameSite attribute.
Proof of Concept (PoC):
Step 1:
Authenticate through the custom web application login page, load the power BI report and capture a request using Burp Suite.
Step 2:
Observe the response headers and identify cookies set without the SameSite attribute.
The details using Burp Suite, along with the observed impact.
| Capturing request using Burp Suite tool | |
| Request | Response |
| Pretty | Pretty |
| GET /13.0.27916.28/sharedresources/BaseThemes/CY24SU08.json HTTP/2 | HTTP/2 200 0K |
| Host: app. powerbi.com | Content-Type: application/json |
| Cookie: ai_user=32=80+PC1/8k:54nyALpTPs | 2026-03-12T05:19:17.9832; | Date: Sun, 15 Mar 2026 14:53:26 GMT |
| WFESessionId=81ed4d92-9497-4ec2-be8d-329bba45ee6c; | Accept-Ranges: bytes |
| ARRAffinitySameSite= | Access-Control-Allow-Origin: https://teams.powerbi.com |
| 0632ca9db79921cff52d39e8281a****464dlc11d97e789130cd466b********; | Cache-Control: public, max-age=31536000 |
| ai_session=juq7door******Mk1gMNLB | 1773585611908 | 1773585611908 | Itag: "0694a6159b3dcl:0" |
| Sec-Ch-Ua-Plat form: "Windows" | Last-Modified: Sat, 14 Mar 2026 02:22:18 GMT |
| Accept-Language: en-US, en; q=0.9 | Vary: Accept-Encoding |
| Sec-Ch-Ua: "Chromium" ;v="145", "Not : A-Brand" ; v="99" | Content-Length: 19684 |
| Sec-Ch-Ua-Mobile: ?0 | Strict-Transport-Security: max-age=31536000; includeSubDomains |
| Requestid: 4791f056-f27a-70b3-b048-1e2f5f724dlc | X-Content-Type-Options: nosniff |
| User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) | X-Xss-Protection: 1; mode=block |
| AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 | X-Frame-Options: deny |
| Safari/537.36 | Content-Security-Policy: frame-ancestors https://teams.powerbi.com |
| Accept: application/json, text/plain, */* | 'self' https://res-sdf.cdn.office.net https://res.cdn.office.net |
| Activityid: 8b27f0d6-****-8d5c-0540-8clcaa97**** | https://mesh.public.onecdn.static.microsoft |
| Sec-Fetch-Site: same-origin | https://m365.cloud. microsoft https://outlook.cloud.microsoft |
| Sec-Fetch-Mode: cors | https://teams.cloud.microsoft https://teams.microsoft.com |
| Sec-Fetch-Dest: empty | https://gov.teams.microsoft.us https://dod.teams.microsoft.us |
| Sec-Fetch-Storage-Access: active | https://teams.microsoftonline.cn https://outlook.office.com |
| Referer: https://app.powerbi.com/report Embed?uid=d6shx | https://outlook-sdf.office.com https://outlook.office365.com |
| Accept-Encoding: gzip, deflate, br | https://outlook-sdf.office365.com https://www.office.com |
| Priority: u=l, i | https://scuprodprv.www.office.com https://www.microsoft365.com |
| https://local. loop.microsoft.com https://dev. loop.microsoft.com |
Impact:
An attacker may be able to:
- Perform unauthorized actions on behalf of the victim
- Modify account details (possible account takeover scenarios)
- Access or manipulate sensitive data
- Execute transactions without user consent
The security team also provided recommendations, but for the app.powerbi.com domain, we do not have control over cookie settings. Is that correct?
Recommendation provided by security team:
- Set the SameSite attribute for all sensitive cookies
- SameSite=Strict (recommended for maximum protection)
- or SameSite=Lax (if cross-site navigation is required)
- Ensure cookies are also configured with:
- Secure
- HttpOnly
- Implement CSRF tokens for all state-changing operations
- Validate Origin/Referer headers on sensitive requests
Could someone please clarify whether this is something Microsoft controls for the Power BI domain, and whether there is any supported mitigation from our custom web application backend side in an app owns data embedding scenario?
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.
7 Replies
- SamInogic
Super User
Hi,
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!
- Nagaraj_D
Hi 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.
- v-abhinavmu
Hi Nagaraj_D,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to SamInogic for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
- v-abhinavmu
Hi Nagaraj_D,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank you. - v-abhinavmu
Hi Nagaraj_D,
May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.
Thank you - DataTako
Resolver IV
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.
