X-Frame-Options for Outlook Web Add-Ins

Question

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?

Aery

Answer 1

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.

Plateau

How do you recommend combating clickjacking without setting the X-Frame-Options header? According to Combating ClickJacking With X-Frame-Options, ideally Outlook would include origin information in the request, which could be verified prior to header being sent. – Aery

To get around that, use the displayDialogAsync where X-Frame-Options are allowed. – Plateau

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? – Aery

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: #43667926 – Plateau

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. – Aery

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." – Velocipede

@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? – Aery