6

I'm working on an Outlook Web Add-In and I'm struggling with knowing what value to set for the X-Frame-Options: ALLOW-FROM header. As far as I know, users may access Outlook via three different domains (office.com, office365.com and live.com). Does anyone know how I can tell which site is making the request, so I can set the header appropriately?

Ryan Robertson
  • 61
  • 1
  • 5

1 Answers1

0

The add-in needs to be able to run in an iFrame in order to work in Outlook Web, thus X-Frame-Options header should not be included at all. ALLOW-FROM can't really be used because the number of domains to list is way more than 3 mentioned, and that list is growing – there are many cases where various users access Office365 and outlook.com using custom domains.

Outlook Add-ins Team - MSFT
  • 8,906
  • 1
  • 9
  • 21
  • How do you recommend combating clickjacking without setting the X-Frame-Options header? According to [Combating ClickJacking With X-Frame-Options](https://blogs.msdn.microsoft.com/ieinternals/2010/03/30/combating-clickjacking-with-x-frame-options/), ideally Outlook would include origin information in the request, which could be verified prior to header being sent. – Ryan Robertson Jan 29 '18 at 17:36
  • To get around that, use the [displayDialogAsync](https://dev.office.com/reference/add-ins/shared/officeui.displaydialogasync) where X-Frame-Options are allowed. – Outlook Add-ins Team - MSFT Jan 29 '18 at 19:06
  • 1
    I use `displayDialogAsync` to display a dialog box to handle authentication, but how is that useful for the initial page load of the add-in? – Ryan Robertson Jan 29 '18 at 20:59
  • Could you not allow the user to user your add-in until they have been authenticated? So if someone loads you in an iframe your add-in is useless until they login? Also take a look at this post: https://stackoverflow.com/questions/43667426/trusted-way-to-get-the-host-origin-of-an-office-add-in – Outlook Add-ins Team - MSFT Jan 30 '18 at 18:49
  • I think I understand what you're suggesting. It's a bit counter-intuitive to only set `X-Frame-Options` on the login page, but I'll give it a shot. – Ryan Robertson Jan 30 '18 at 22:44
  • How does using a pop-up for the login protect against clickjacking for the rest of the addin? In the linked answer you say: "If the user re-enters credentials at that point, then you could be hosed." – Ryan Quinn Feb 01 '18 at 23:46
  • @OutlookAdd-insTeam-MSFT, I understand the suggestion around requiring login prior to enabling the functionality in the add-in, and that my login page can be served with `X-Frame-Options` since it's opened in a dialog window. I am still concerned with the lack of an `X-Frame-Options` header for the add-in after users have authenticated. Wouldn't it be better for the Outlook to pass the origin / referrer in the initial request, and then provide an endpoint that my server can use to validate the request against Outlook's list of approved domains? – Ryan Robertson Feb 05 '18 at 22:32