XSS vulnerability in iframe attribute src

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.

Thanks for reporting this, @davidgabrichidze.

Security and dependency issues are important. The GrapesJS team actively works on keeping dependencies up-to-date.

For you right now:

1. Run npm audit fix to see available patches
2. Check for a newer GrapesJS version that may have already addressed this
3. If available, test the latest stable release before upgrading
4. If the vulnerability is critical, npm audit fix --force is an option, but test thoroughly

Understanding the risk:

• Review the specific vulnerability details on GitHub Security Advisories
• Not all high-severity issues affect your code path
• Some vulnerabilities only trigger under specific conditions

Staying current:

• Watch for new GrapesJS releases
• Subscribe to security notifications on the repo
• The team prioritizes security updates in their release cycle