I now have several add-ins in AppSource and all doing well. But one in particular is getting a LOT more attention than others: “Send to Planner.” While popular with the general public, IT admins are not because it needs so many permissions. I wrote a fairly complex explanation to why it needs to many permissions: https://kryl.com/?page=kb&id=31. Ok, so some say – fine, I trust that, but others want more, a lot more, like my latest Penetration Testing Results. They also ask for more than attestation and wonder why I am not on the Office 365 certified list… me too, it turns out…
Sidebar first… This is leading somewhere, I promise…
So, Office 365 Certification… I jump through God knows how many hoops to try to get my Office 365 certification rather than just a generic Publisher Attestation. I have to provide a TON of documentation and one of the artifacts is a good penetration test which are actually a LOT of work. Anyway, after a few weeks of gathering information, study on how to do this, that or the other thing, a ton of back-and-forth in email… I was told…
“Well, so, yeah… Your company is… yeah… just not big enough for us to consider you.”
So, when I submitted the VERY FIRST FORM with employee count you still let me proceed! I waste weeks, collecting and finagling and answering to artifacts and this… Ugh! Anyway, it was an educational experience and from that, I learned how to create a good Pen Test document.
…Back to the main attraction. Turns out to make administrators HAPPY, you need to have a really good Pen Test and one of the picker areas they remark upon is your sites Content Security Policy. I use an NGINX server in Azure. It took a LOT of finagling to get it restrictive enough for me to score an A+ on https://securityheaders.com:
script-src 'self' https://p.trellocdn.com https://alcdn.msauth.net https://cdn.msftauth.net https://login.microsoftonline.com https://login.live.com https://*.trello.com https://*.asana.com https://appsforoffice.microsoft.com;
In my QA testing, everything seems to be humming along with my A+ except that I started noticing my add-in failing to load sometimes. Pop open the F12 developer tools and viola, a MicrosoftAjax.js error that is failed to load because of my CSP. So, I added it:
script-src 'self' https://p.trellocdn.com https://alcdn.msauth.net https://cdn.msftauth.net https://login.microsoftonline.com https://login.live.com https://*.trello.com https://*.asana.com https://appsforoffice.microsoft.com https://ajax.aspnetcdn.com;
That seemed to make it happy, and my QA succeed so I published. I had figured it must be something in my code, but I did not find Ajax in any of my dependencies or my code base, so I gathered it was from office-js (rightly so), but no big deal, right. I did an NPM UPDATE and grabbed another coffee.
But then users started to contact me that they were unable to use the add-in. Why? Well, turns out in certain conditions my code did something that would fail. And after a lot of troubleshooting, I start to see this error around areas where I am getting mailbox session data:
Cannot read properties of undefined (reading ‘cannotDeserializeInvalidJson’)
at Sys.Serialization.JavaScriptSerializer.deserialize
So, oh boy… 2015 wet sock moment… the Microsoft Office JS library apparently injects the MicrosoftAjax.js library right into your taskpane page and uses it for JSON.parse(). What?
Send to Planner (and my other add-ins) were all showing this. And I had NEVER seen this Ajax error before — so it was new. I scoured the web, asked my new buddy Chat GPT and… long story short, because this was something new… What did I do… Pen Testing… Yes, and what did I recently change… Oh, yeah, my CSP. Yes… more digging, trial and error:
script-src 'self' 'unsafe-eval' 'unsafe-inline' https://p.trellocdn.com https://alcdn.msauth.net https://cdn.msftauth.net https://login.microsoftonline.com https://login.live.com https://*.trello.com https://*.asana.com https://appsforoffice.microsoft.com https://ajax.aspnetcdn.com;
Well, now I only have an A on security headers, and I get a nice little blurb about:
This policy contains ‘unsafe-inline’ which is dangerous in the script-src directive. This policy contains ‘unsafe-eval’ which is dangerous in the script-src directive.
Inline is one thing and good use of input sanitization with DomPurify (thanks MichaelZ), corner cases that. But unsafe-eval? I confirmed – on/off/on/off – yep… it needs to be there.
Anyway, it was a long journey – many hours – and I am wiser for it. I know this is probably because OfficeJS still supports versions back to Office 2013 and Edge before it went the path of the Chromium, but I hope maybe it can move away from needing eval() code and the MicrosoftAjax.js library in the near future and I can add a (+) back to my security posture.
Hopefully, this post will help others from tripping up on this as they lock things down.














