BUG: XSS vulnerability in iframe attribute src

I think the pre-parser option is a really good idea. It sticks to the 'plug-in' per feature concept.

How about updating fromElement to accept a string element ID or boolean. If bool == true, works as it does now, parsing the container HTML. If a string ID, it uses the contents of the element and the container becomes the editor as it does now. Then we could update the docs in favor of a HTML script template for development. This prevents any braking changes, and promotes proper usage.

const editor = grapesjs.init({
  container: '#gjs',
  fromElement: '#mySource',
  height: '100%',
  storageManager: { type: 0 },
  plugins: ['gjs-blocks-basic']
});

Totally agree with @bernesto indeed no matter how hard we try to make it safe, it will never be enough and I don't want to give the impression that the library is "so safe" to justify a missing server-side validation. The current options (eg. allowUnsafeAttr, allowUnsafeAttrValue) avoid only the basic common stuff.

This is unavoidable when using fromElement to load from an active DOM element. The element of the page loads and executes synchronously. GrapesJS would never have a chance to process and disarm the XSS html.

This would need to be addressed by preventing the malicious code from ever loading. This should be handled at the server on save. But, if on the client processing is needed, by wrapping the code in script tags, and then sanitizing the code prior to loading it in to the editor like this:

https://jsfiddle.net/bernesto/5gcxa0jm/1/

I do see that when loading via the components property at initialization or dynamically post from a remote source, the same XSS vulnerability exists, and this may be something we want to prevent.

Personally, I believe that the server should be processing all saves and sanitizing. A malicious actor could always emulate a client request and save an malicious XSS to your server regardless of the editor used.

@artf what do you think?

In your opinion, should an XSS sanitizer be built into the editor? And if so, that begs the question; how do you feel about fromElement anyways? Should it be reimplemented as something similar to my example, where content is provided using script tags instead? E.g. maybe providing a source (script template) and destination (editor) element IDs instead?

Not only would this allow us to sanitize for XSS vulnerabilities, but it would also eliminate the browser processing and painting those initial DOM elements twice (once on load, second to the new frame). This may actually speed up the editor load time as a happy benefit.