Just because I can should I use Private Office 365 CDN
Anatoly Mironov
This is about a topic brought up by Waldek Mastykarz: Just because you can should you use the Office 365 CDN. In my post I want to take a closer look at the private CDN option in Office 365. Please note, the whole thing is subject to change, and it reflects the circumstances at the time of writing - 2019-08-26.
I’ll skip the introduction of Office 365, let’s jump directly to the Private CDN option. Consider following scenarios.
I am developing SPFx solutions, is the Private Office 365 CDN something for me?
No, you can’t use private CDN for SPFx, because SPFx cannot handle changing Urls from a Private CDN.
I use Modern Team Sites and Communication Sites. Is the Private Office 365 CDN something for me?
No, the urls are changing. You cannot “hardcode” them. Automatic URL Rewrite works only on classic Publishing Sites.
I have Provider Hosted Add-Ins. Is the Private Office 365 CDN something for me?
No, the referrer needs to be a subdomain of sharepoint.com.
Security
The whole point of having a private CDN is that it is not available for strangers. But when you enable it, you’ll see an eligible warning:
WARNING: This is a feature built on a 3rd party application with privacy and compliance standards that differ from the commitments outlined by the Microsoft Office365 Trust Center. Any data cached through this
service does not conform to the Microsoft Data Processing Terms (DPT) and is outside of the Microsoft Office365 Trust Center compliance boundaries.
The risk might be low, but if an attacker gets a url that looks like this: https://privatecdn.sharepointonline.com/takana16.sharepoint.com/sites/cdn/privatecdnorigin/africa_private.jpg?eat=1566833073_cc22be0bd8c3534b83bbf38cfa3aa013923baa670e0874303efaaae1e9a86da7&oat=1566833073_5951c0c968da9de384f63b556ad42915aa01 then it is just a matter of downloading within 30-90 minutes. That’s how long those tokens in the URL are valid.
Adding Referer: <subdomain>.sharepoint.com as a Request Header is needed to download a resource.
If you remove an asset from the private cdn origins, it takes up to 15 minutes for the link to be invalidated. Opposed to an immediate effect for a direct link to an asset in a document library.
To keep it more secure, the default private cdn origins should not be included, especially */SITEASSETS, Because site assets can have important information, and this makes every single site assets library vulnerable, asterisk means all.
Even the CDN Policies should be restrictive.
Overall, if the usage area is small, the performance gain is little, we should not enable it at all. Because: any cached data in a private Office 365 CDN is outside of the Microsoft Office365 Trust Center compliance boundaries.
Performance
I have tried the private CDN. My setup was a document library with three versions of a picture that was 2,4MB that I put to three different libraries:
- privatecdnorigin/africa_private.jpg
- publiccdnorigin/africa_public.jpg
- nocdnorigin/africa_nocdn.jpg
On the publishing site I inserted three images on a page and compared the load time in the DevTools. During this test I had Cache Disabled. I got following results:
- private, public, nocdn
- 3.04s, 3.03s, 3.24s
- 1.78s, 1.77s, 1.75s
- 1.99s, 1,95s, 3.32s
- 1.67s, 0.73s, 0.72s
- 1.73s, 1.71s, 1.97s
- 1.60s, 1.58s, 1.67s
So only once I got a bigger difference, otherwise it took the same time to load a picture from a document library without CDN.
To be fair, it is a very simple performance test. Tests with bigger files, different geographical locations would probably give a more detailed view of that. And still, without a URL Rewrite that is only present on Publishing sites, you cannot take use private cdn origins.
Conclusion
Private CDN in Office 365 can be interesting in future, but today, the usage is narrow (only publishing sites can refer to assets in a private CDN), the performance gain is little and lower security makes it to a bad choice.