(I know this topic has been discussed a lot in the past, and I've read a lot of threads here as well as OWASP, but have additional questions including the specific CSP listed below.)

We want to allow our users to write each other messages via a WYSIWYG editor, which allows html. So user1 sends user2 a message, we of course display that message to user2; a scary scenario to say the least.

Assuming that we use this editor which allows HTML, is the following plan about as safe as we can hope to be while still allowing a smooth user experience? The editor itself called "Trix" is used and actively maintained by a large company, Basecamp, and they are using it in production for a similar use case. So while I would prefer for security reasons to use markdown and stripping all user input html, if Basecamp can use the editor relatively safely, I would hope we can too.

Our plan is:

  1. Use HTML Purifier to whitelist

  2. A "strict" CSP, specifically Google's proposal: https://csp.withgoogle.com/docs/strict-csp.html

The CSP:

  object-src 'none';
  script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
  base-uri 'none';
  report-uri https://your-report-collector.example.com/

1 Answer 1


The editor is great for usability, but it should really be ignored when taking about security against XSS.

It's the sanitizer running on the server that needs to take care of ensuring security of injected HTML. No amount of fiddling in the browser is going to completely protect the user against unsanitized input if you need to mix in HTML (OTOH, if you just want plain text, that's simple, just use innerText).

  • Thanks, I was under the impression that no sanitizer is perfect/black hat folks are constantly trying to come up with ways around sanitizers, so browser-related protections like a CSP and (what else?) are important lines of defense Commented Jun 20, 2019 at 14:41
  • To further drive the point, consider this: A malicious actor can bypass any client-side code and just make a http post with whatever they want. So relying on client-side sanitation/validation is bad
    – Artog
    Commented Jul 16, 2019 at 13:00
  • "relying on client-side sanitation/validation is bad" - yup: client-side is for looks/UX, server-side is for security
    – jleach
    Commented Jul 16, 2019 at 15:08

You must log in to answer this question.

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