XSS sanitization in backend and usage of DomPurify and jsdom with pocketbase #6694
-
|
Hello community, kindly seeking for guidance regarding a security issue and how to do html sanitization in the backend with pocketbase. What is the matter?Specifically I want to sanitize user input that might contain malicious code. I want to use JS hooks for this purpose. I can do this in the frontend, however I want to prevent, that by means of third party tools xss content could still be sent through the pocketbase API and enters the database, hence the next time the backend delivers this content to the client, XSS would be executed in the browser on the client. What would be the desired goal?Pocketbase either out-of-the-box or by implementing a hook, specifically How did this become a thing?Why does this content get rendered on the client? Because I have a rich editor field, where users essentially can create some formatted text and the html content would be rendered verbatim using v-html, but any other technology/tool like using What have I tried until this point?I tried to make use of DomPurify in the backend with pocketbase using hooks specifically to further strenghten the application and prevent xss code injection into my database. DomPurify explicitly describes it can be used on the server. However it also says on the server you would need jsdom to create a DOM of the to be sanitized content and then use DomPurify on it. DomPurify provides a cjs file, as I understood Pocketbase supports CommonJS only when using JS, I got that information from here https://pocketbase.io/docs/js-overview/#loading-modules Because Possible solutions I did think of
Thank you for your time and help, best regards Jacky |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
The PocketBase UI should be XSS free no matter what the user submits. We ensure this by serving a default Content Security Policy (CSP) and by minimize rendering untrusted raw HTML (we do render raw HTML as part of the TinyMCE preview but it is considered safe because it performs its own HTML sanitization and even if something manage to slip through it the CSP should catch it). Regarding If you really want to perform the sanitization on the server-side then I'd recommend using Go and the If you are working on a SPA I personally wouldn't do even that and instead will perform the sanitization in the browser right before passing it to |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @ganigeorgiev for your quick answer, you even took time to look into jsdom, I highly regard your evaluation regarding that! I have a project that makes use of Nuxt and SSR too, so I think I should not resort to client sanitization only. In the first project, which is an SPA, where I encountered this issue, the client sanitization does represent another protective barrier against XSS additionally to the custom CSP that was deployed there. However it would be really nice, if we could sanitize in the backend as an additional defensive barrier in order to prevent stored xss attacks in addition to deploying a CSP. So do you by chance have any advice how one could approach this, considering having little to no knowledge in Go programming? Would the chapter of your documentation here https://pocketbase.io/docs/go-overview/ serve as a good starting point? Thank you again for your time and help. Another edit: I have seen that some users of |
Beta Was this translation helpful? Give feedback.
-
|
Without a concrete code sample or at least some more detailed context about your actual project I don't think I can help you further as I don't know what else to suggest. It is not even clear what actually you want to sanitize, what tags and attributes should be stripped/disallowed, what about css styles, how images and links with external urls should be handled if allowed at all, etc. You need to identify first what actually is the issue you are trying to solve and protect from. If you really want to protect against stored XSS attacks then this means that you'll have to sanitize every possible user submitted text field (name, title, etc.) and this usually is not worth it, not only because it would be extremely inefficient but because XSS is foremost a client-side vulnerability. If you want to extend PocketBase with Go, then Yes, getting familiar with the Overview section and the other Go related guides is necessary to make the most of it. You can find the |
Beta Was this translation helpful? Give feedback.
-
|
You got a point, thank you for your perspective, I will prepare a code sample, the points you mentioned they are totally valid in the context of the earlier mentioned provided user rich text editor use case. The rich text editor is deployed in just a few instances, it would be very helpful if those fields can be sanitized in the backend. First I thought it would be necessary to sanitize all possible inputs, but your advice against it due to several reasons, I will consider it. I will further look into it and can restrict the attack surface. Thank you again for your advice and time @ganigeorgiev I have accepted your first answer for the time being. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: if someone in the future is looking for examples regarding this matter, I made a minimal demo, where I used |
Beta Was this translation helpful? Give feedback.
The PocketBase UI should be XSS free no matter what the user submits.
We ensure this by serving a default Content Security Policy (CSP) and by minimize rendering untrusted raw HTML (we do render raw HTML as part of the TinyMCE preview but it is considered safe because it performs its own HTML sanitization and even if something manage to slip through it the CSP should catch it).
Regarding
jsdom-jsdomalready seems to be a CJS module but it won't work with the PocketBasepb_hooksbecause it relies on Node.js specific APIs such aspath,fs,vm, etc. You can try searching for an alternative pure JS library but I would advice against it because usually html sanitization libraries are very co…