We at ShortPoint engineering team take security very seriously. Our product enhances the features of the battle-tested rich text editor used in SharePoint, Office 365, SAP and other platforms; nevertheless, that does not mean we should take everything for granted.

In this document we’ll go through each potential threat in SharePoint / Office 365 / SAP, and how we have addressed those threats and increased the level of security in ShortPoint.

ShortPoint is fully compliant with Microsoft Office 365, SharePoint and SAP Cloud Security principles and implementations

After you download the package, you install ShortPoint entirely into your environment. We do not have access to your content at all. ShortPoint is fully compliant with Microsoft Office 365, SharePoint and SAP Cloud Security principles and implementations.


To make sure that end user’s input through ShortPoint remains safe all the times, we have added a Filters Layer into the product, that depends on two of the most well-known XSS filtering libraries out there ( XSS-Filters by Yahoo Engineering & the popular JsXss Node module ). We have used a mix of those two modules to fit our special needs in handling every aspect of user input in ShortPoint while not breaking important part of the end-user's page.

 Figure 1: ShortPoint Filtering Security Layer

It is good to note that the Filters layer is not tightly coupled with those modules, so updating any of those modules is just a matter of one click, and if we wanted for any reason to drop any of those modules or replace them with a better alternative in the future, it can be easily done by updating only this layer.

Let’s dive into each potential XSS threat that we have found in our product, and how we managed to address those threats to protect Office 365, SharePoint, SAP CP and other users as much as possible. 

Non-Logged In Users

Since XSS attacks come from an in-validated user input, please note that all forms that require user input in ShortPoint / SAP can only be accessed when the user is actually authenticated and authorized.

ShortPoint Generator ( SharePoint Only )

ShortPoint Generator page is used to allow user to define a template for a content once, and use this template in every page that ShortPoint runs on. This template may contain HTML & ShortPoint elements as well.

Since the template may contain HTML, then it may also contain <script> references, javascript handlers like ( onclick, onmouseover, ..etc ), which allow the end user to write a script that could be run in multiple pages.

Using the filters layer mentioned previously, all ShortPoint generated content goes through the filtering mechanism, to make sure that all written code is clean and safe.

Branding & Settings ( SharePoint Only )

Similar to the Generator Page, All data entered through the Branding and Settings “Change the Look” page will go through xss filtering mechanism as well, before storing them.

SharePoint Lists Content ( SharePoint Only )

Protecting both Branding & Generator pages in ShortPoint, does not mean end-user is safe, since all of the user preferences created by these pages are stored into a repository (ex: SharePoint lists), end-user can go right into those repositories, and add whatever script code that he wants, and those scripts will end up being executed on pages that have ShortPoint enabled on.

to prevent this, the same filters that were applied to Branding & Generator pages mentioned in the previous sections were applied again before injecting any content from ShortPoint repositories into the page.

Page Builder Text Fields Input

The page builder is the most area in ShortPoint that contains text fields, each ShortPoint design element can be customized using a bunch of text fields, and it is important to make sure that every field does not contain any potentially harmful code by the end user. All inserter fields will be validated using the ShortPoint filters layer to make sure entered data are safe and clean.

Page Builder Rich Text Editor

To enable end-users to write rich text content from the Inserter Dialog, we have carefully picked a highly flexible & secured rich text editor to do this job ( Froala Editor ). Froala editor has a strong defense mechanism against all types of XSS attacks. It was tested by the world-renowned Ashar Javed.

Manually Writing ShortPoint HTML

All ShortPoint elements before rendering, will almost look as the following HTML template

<div data-shortpoint=”ELEMENT_NAME: { OPTIONS }”></div>

We used to parse the data inside data-shortpoint attribute using the eval method, allowing end user to write harmful code inside such attribute as in the following example 

<div data-shortpoint=”button: { title: ‘about us’, link: alert( 1 ) }”></div>

To prevent this, and since all content of the data-shortpoint attribute should be raw data, the parsing mechanism has been updated to use the safe JSON.parse method instead of eval. 

Explicitly Defined ShortPoint Code Attributes

After going through how ShortPoint works behind the scenes, and how that ShortPoint Code get parsed into an actual JavaScript code, one may think that any attribute you put into the code will end up being parsed into the data-shortpoint attribute, but it is not the case here.

for example, given the following ShortPoint code:

[button title=”hello world” onclick=”callSomething” onmouseover=”callAnother” /]

Once it is converted into a ShortPoint HTML template, it will look like the following:

<div data-shortpoint=”’button’: { ‘title’: ‘about us’ }”></div>

As you can see all extra attributes in ShortPoint code, has been removed once converted into a ShortPoint HTML template, and the reason is that for every ShortPoint design element, we have a meta-data definition ( see figure 2 ) for it that will define the exact attributes that need to be parsed.

Any extra attribute is written into the ShortPoint code, that is not defined in the ShortPoint element meta-data, will not be parsed, and will be ignored.

 Figure 2: Button ShortPoint element meta-data definition

Injecting JavaScript Data

All data that are passed from ShortPoint repositories, were updated to be serialized using the safe JSON.stringify method to serialize JavaScript object, instead of normal string concatenation methods.

JavaScript Source Protection

Our javascript is not only being minified, we’re obfuscating them using JsCrambler 

Most products designed to protect JavaScript rarely go beyond simple regular expression transformations. However, JScrambler is a JavaScript interpreter and parsing engine that creates an Abstract Syntax Tree representing the source code. Because JScrambler understands JavaScript, it secures the HTML5 and JavaScript in a way that the protected code executes with the same functionality as the source. This approach allows the product to be easily and affordably maintained, enabling it to evolve naturally and providing it with the ability to produce enterprise-class security and anti-debugging methods.