Avoid XSS vulnerabilities in custom Widget templates

Introduction

This document explains how to structure widget template customizations so that users cannot introduce cross-site scripting (XSS) vulnerabilities. The basic concept is prevent user from editing templates through domain separation of users and templates.

Default domain model for template setup

Setup	Comment
Templates in the root domain	By default, all widget templates are stored and executed in the root domain.
Ordinary users in subdomains	By default, all ordinary (non-admin) users are not in the root domain, but in a subdomain of the root.
No template editing from subdomains	Users whose accounts are bound to subdomains cannot edit any templates in the root domain. As a result, they cannot inject XSS code into widget templates.

Default model: admin rights and risks

Setup	Risk
Admin users in the root domain	Admin users, who operate directly in the root domain, can always edit templates.
Admins can inject code (including malicious)	Because of their elevated privileges and same-domain access to template assets, admins are technically able to add any code, including malicious or vulnerable code. This is an unavoidable property of admin-level access.

The core risk

The core risk is based on the same-domain edit capability:

As soon as a user is in the same domain as a template asset that user is technically able to edit the template. He can then inject arbitrary code (including XSS).

Key rules to minimize XSS risk

Ensure:

Object	Security rule
Standard users	Standard users are always working in subdomains.
Template assets	Template assets are stored in a higher domain which standard users cannot access. Typically, this is the root domain.
Domain access	Standard users do not have access to the same domain which also contains the template assets. Without direct access to template assets, standard users also cannot modify the templates.

No sanitize mechanism: Censhare Cloud does not integrate any filtering on input/output data for template widgets. This way, existing custom solutions can continue to work as they are.

If you do not follow a strict domain separation, it is on your responsibility to take appropriate actions such as filtering of input/output data.