(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/

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).

| improve this answer | |
  • 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 – KayakinKoder Jun 20 '19 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 Jul 16 '19 at 13:00
  • "relying on client-side sanitation/validation is bad" - yup: client-side is for looks/UX, server-side is for security – jleach Jul 16 '19 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.