Document required CSP values

[richnew10]

"Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context."

https://en.wikipedia.org/wiki/Content_Security_Policy

A site with a CSP tag — which, ideally, should be every site — should whitelist individual domains that are needed for functionality.

The ones I've found so far for office.js, by manual testing, are:

script-src 'self' https://appsforoffice.microsoft.com:* https://ajax.aspnetcdn.com:* https://browser.pipe.aria.microsoft.com:*

Can we get a canonical list for this?

[JuaneloJuanelo]

@AlexJerabek seems to be a documentation gap

[AlexJerabek]

Hi @richnew10,

I'm researching the answer to your question with the product team. I'll update the documentation when I get a complete domain list.

In the meantime, I'll get this issue moved to the documentation repo, since this is not a product bug.

[AlexJerabek]

Hi @richnew10,

Here's the response I received from our product team:

"https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges shows all the IP ranges and domains Microsoft Office uses, use which includes our CDN networks as well.

When I check, Office CDN uses 198.105.244.114 and this is not part the IP list, but is part of the o365 list. So, hopefully the customer can take this list and allow traffic to come from IP/domains. This is also not a static list and should be kept in-sync to account for changes. "

[richnew10]

Thanks for chasing. I'm not asking about network ACLs; that's not how CSP works.

CSP is a directive that has a webpage tell the browser which origins — e.g., appsforoffice.microsoft.com — should be usable for various kinds of action, e.g., loading script content, or connecting websockets.

The list your product team provided is not sufficient or precise enough for CSP. For example, it lists

ajax.aspnetcdn.com

as "Default Optional; Notes: Office 365 Video CDNs", but office.js loads code from that domain, and omitting it from CSP will cause an error when loading the add-in. On the reverse side,

passwordreset.microsoftonline.com

is listed as required, but that origin will never be accessed from an Outlook add-in or from office.js, and arguably that's exactly the kind of security safeguard that CSP is intended to provide!

What I'm specifically asking for is a list of domains/URLs that the contents of office.js will try to load, and are necessary for office.js to function, and secondarily a mechanism for finding out when that list changes.

You can probably find this out by grepping for https in office.js, and applying a little reasoning.

I have found the following empirically:

https://appsforoffice.microsoft.com:*
https://ajax.aspnetcdn.com:*
https://browser.pipe.aria.microsoft.com:*

Are there more?

[dmahugh]

Hi @richnew10,, thanks for bringing this up. I don't have anything to share yet, but just wanted to let you know we're looking into how to handle CSP documentation going forward. I'll leave this issue open until we have a resolution.

[Reezaali]

Internal bug

[lindalu-MSFT]

In backlog: #3226763

[jak-hammond]

We have recently undergone a pen-test of an application we are building utilizing Office.js and this was one recommendation they suggested we implement, so obviously the sooner we can get this documented, then the sooner we can all implement the best practices :)

[mwickens]

Any update on this? We also just had a pen test and this came up. It's not clear how we should construct a security policy for our Outlook add-in.

[Jarch09]

Any updates here? Kind of crazy this hasn't been resolved yet.

[ElizabethSamuel-MSFT]

@jeremy-msft Any current status on this? Thanks.

[Paul-Morton-Hyland]

We have run into questions with this as well while building our outlook add-in. Is there a documented list of CSP URLs that we need to include, yet?