Share via

Outlook Add-in manifest specifies sub-path URL but New Outlook performs framing check on root domain instead

Laskowski, David 0 Reputation points
2026-06-17T14:34:05.21+00:00

I am developing an Outlook Add-in where the taskpane URL in the manifest is configured to a specific sub-path (https://subdomain.domain.com/msoffice-plugin/index.html), not the root domain.

When installing the add-in in New Outlook (browser-based), the browser console shows:

Refused to display 'https://subdomain.domain.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

The error references the root domain (/), not the manifest URL (/msoffice-plugin/index.html). The root domain has X-Frame-Options: sameorigin set globally via a server security policy which I cannot currently change.

Question: Why does New Outlook perform a framing/reachability check against the root domain instead of the URL specified in the manifest? This behavior does not occur in Classic Outlook. Is this a known behavior and is it documented anywhere?

If New Outlook is indeed checking the root domain before loading the add-in, would setting permissive frame-ancestors CSP headers on the root domain (in addition to the actual add-in path /msoffice-plugin/) fix this issue?

Manifest snippet:

<bt:Url id="Taskpane.Url" DefaultValue="https://subdomain.domain.com/msoffice-plugin/index.html"/>
Microsoft 365 and Office | Development | Other
0 comments No comments

2 answers

Sort by: Most helpful
  1. Hin-V 16,065 Reputation points Microsoft External Staff Moderator
    2026-06-17T16:33:19.54+00:00

    Hi @Laskowski, David

    Thank you for reaching out. 

    Based on my research, this behavior is expected in New Outlook. Unlike classic Outlook, New Outlook runs add-ins in a browser-based environment, which enforces standard web security rules. These rules operate at the domain (origin) level rather than the URL path level, so even if a sub-path is specified in the manifest, the browser evaluates the response headers of the root domain.  

    Because your root domain returns X-Frame-Options: SAMEORIGIN, the browser prevents Outlook (which runs under a different domain) from embedding the page in an iframe, resulting in the issue you are seeing.   

    image

    Reference: Address same-origin policy limitations in Office Add-ins - Office Add-ins | Microsoft Learn 

    Regarding configuring CSP (frame-ancestors), as far as I understand, this approach can be effective if it is applied at the root domain level and no conflicting headers remain. Since New Outlook operates in a browser-based environment, framing decisions are enforced at the domain (origin) level rather than at a specific add-in path. This means that configuring frame-ancestors only for /msoffice-plugin/ is not sufficient. 

    To fully resolve the issue, the root domain must explicitly allow iframe embedding, for example: 

    Applying the frame-ancestors directive at the root domain level. 

    Ensuring that restrictive headers, such as X-Frame-Options: SAMEORIGIN, are removed or appropriately adjusted. 

    Please note that this summary is based on my own findings and may not fully address your concerns. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment and configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance.   

    Apologies for redirecting you to the related development team support. As moderators in this community, we do not have access to your specific tenant configuration, and my testing environment is limited. Therefore, my guidance is based on available Microsoft documentation and resources. That said, I’ll do my best to provide additional insight where possible.   

    If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 


    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

    Was this answer helpful?


  2. AI answer

    2026-06-17T14:34:23.1733333+00:00

    New Outlook and Office on the web treat the add-in’s domain as the security boundary and apply navigation and framing checks at the domain level, not just at the specific sub-path configured in the manifest. This differs from classic Outlook on Windows, which hosts the add-in in a different way and does not exhibit the same behavior.

    From the Office Add-ins manifest model:

    • The add-in’s start page is defined by SourceLocation (or the URL referenced by bt:Url), for example https://verthi2.reisswolf.fit/msoffice-plugin/index.html.
    • For desktop clients, if the add-in navigates to a URL in a different domain than the start page, that URL opens in an external browser unless the domain is explicitly allowed via AppDomains (XML manifest) or validDomains (unified manifest).
    • When running in Office on the web or new Outlook on Windows, the task pane can be navigated to any URL, but the platform still enforces browser security headers such as X-FRAME-OPTIONS and CSP frame-ancestors on the pages it loads.

    Relevant documentation:

    • XML manifest: the <SourceLocation> defines the host domain, and <AppDomains> lists additional domains that can open inside the task pane. The behavior is summarized as:
      • If the domain is in AppDomains, the link opens in the add-in task pane.
      • If not, it opens in the user’s default browser.
    • Unified manifest: the "validDomains" array serves the same purpose for safe navigation.
    • The docs also note that Office on the web/new Outlook can navigate the task pane to any URL, but that does not override the site’s own X-FRAME-OPTIONS/CSP.

    The console error indicates that, as part of loading or validating the add-in’s origin, the browser attempts to frame the root of the domain (https://verthi2.reisswolf.fit/). Because that root responds with X-FRAME-OPTIONS: SAMEORIGIN, the browser blocks framing and logs the error. This is consistent with standard browser behavior when any framed navigation (including redirects or preliminary checks) hits a page with restrictive X-FRAME-OPTIONS.

    The behavior (checking or touching the root domain) is not explicitly described in the provided documentation, but the security model is: Office defines allowed domains at the domain level (AppDomains / validDomains), and the browser enforces framing headers for whatever URL is actually loaded.

    Regarding mitigation:

    • The platform cannot bypass X-FRAME-OPTIONS or CSP on the site. If any part of the add-in load path (including the root /) is framed and returns X-FRAME-OPTIONS: SAMEORIGIN, the browser will block it.
    • Allowing framing via CSP frame-ancestors and/or removing/loosening X-FRAME-OPTIONS on the affected URLs is the standard way to make a site embeddable.
    • To reliably avoid this error in new Outlook/Office on the web, the domain that hosts the add-in (including any URLs that are hit during load, such as /) must not send X-FRAME-OPTIONS: SAMEORIGIN in a way that conflicts with being framed by Outlook/Office.

    So, if new Outlook is performing any navigation or check that hits https://verthi2.reisswolf.fit/, then configuring the root domain to allow framing (for example, via appropriate frame-ancestors CSP and/or removing the restrictive X-FRAME-OPTIONS header) would be required to prevent the browser from blocking it. Applying permissive framing headers only to /msoffice-plugin/ is not sufficient if the root / is still framed or redirected to during the load process.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.