Mura Basics: Cross-Site Scripting (XSS) Protection - Mura Digital Experience Platform
In Flow: The Mura Blog

Mura Basics: Cross-Site Scripting (XSS) Protection

September 10, 2015 by Michael Evangelista

One of the most common vulnerabilities in any web application is found in its html forms. By inserting html, SQL or javascript content into a form element and posting it to the server, malicious code may be executed and damage done in a number of ways. If posted form data is not properly sanitized, practically any website using forms and a database may be open to a cross-site scripting (or XSS) attack.

By default, any xss-suspicious content submitted through a Mura form is automatically stripped and replaced with the [INVALID] marker.

Keeping Things Clean

Mura CMS provides a strong layer of cross-site scripting protection for all form elements, leveraging the tag filtering methods found in Portcullis.cfc to remove any apparent HTML or other scripted code within the values submitted in a form. Any form value deemed to contain an invalid tag such as <iframe> <script> or other potentially unwanted elements is replaced with a custom text string. By default this string is " [INVALID] ", making it very apparent to the submitter and recipient of any form data that disallowed content was attempted and removed. (Also, by replacing the contents of the form field with this marker, rather than simply formatting the contents into safe or usable HTML, the submitter is prevented from easily rebuilding the malicious string based on the stripped-down or encoded contents.)

Potentially malicious html elements such as <script>, <iframe>, <embed> and others are removed from submitted Mura form values.

Exceptions to the Rule

While the built-in protections are robust and smart enough to do their job unmanaged in most situations, there are times when a developer does want to allow coded form field contents to be posted or submitted as-is, especially when working in the Mura Site Manager, where CKeditor is used specifically for the purpose of creating and inserting rich text or HTML content into Mura's database.

Since the cleaning of form content applies to both back-end and front-end forms, the primary rich text editor area for any Mura content item, the Body field, is automatically excepted from this replacement of content with the [INVALID] string, allowing for the full use of restricted HTML tags in this specific admin form field. By default, all other form fields are sanitized and protected from XSS injection.

However, like most systems within Mura, there is a built-in way to customize this functionality. To extend this exception to other form fields in any Mura site, allowing for otherwise restricted tags such as an <iframe> for embedding remote content, simply look for these values in the Mura settings file, found at [site root]/config/settings.ini.cfm: 


If these values to not already exist in the settings.ini.cfm file, it is safe to add them. Then, simply add the field names of any excepted fields to the exceptions list, being sure of case and omitting any extra spaces:


This will allow the matching field names to be bypassed when checking for excepted tags. As with any alteration to the settings.ini.cfm file, be sure to reload the Mura application after saving the changes.

Also see Portcullis.cfc Documentation: Portcullis.cfc by John Mason
Learn more about Mura's powerful features and flexible options at