Protect Express against XSS: is it sufficient to encode HTML entities of whole incoming request?

Question

I have an Express app that I want to protect against XSS.

I red some pages about XSS - including OWASP ones, and in view of my application characteristics, I decide to write a middleware that encode HTML entities - more precisely XML entities, including <>"' - of my request parameters before I use them in the routes .

I also refresh session cookies at connection, to protect a bit against cookie theft.

How I build my app

• All AJAX requests are POST (all parameters are rewritten by the middleware)
• I don't use GET parameters
• The routes params I use are supposed to be int and I raise an error when they are not.
• The only data that doesn't come from user inputs comes from an OAuth personal data retrieving, that I sanitize too when they come in my app
• The client-side JS executed at the page loading involve only data coming from database, supposed sanitised by the middleware when they enter the DB.
• window.location is used safely
• I don't use yet any external client-side JS library (as JQuery or FileUpload) - perhaps I will add them later in the code
• When a user inputs something, it is always sent to the server (via AJAX POST) an I take the opportunity to send back the sanitised input to use it in the JS and/or DOM instead of the initial input
• I don't use eval

My feeling

I conclude that with that behaviour (sanitize external data as they come) I avoid all stored and reflected XSS, and the correct use of windows.location prevent me against DOM based XSS.

Is this conclusion right, or do I forget something? Should I also use some helmet functionnalities?

Edit

My question is not what's the best HTML sanitizer server-side (even if it's a part of it), I rather ask to know if globally the protections I put in my code protect my app against all well known types of XSS. In particular I would know if my middleware is not a bad practice.

Indeed XSS filtering function in PHP doesn't cover at least the DOM based XSS attack (because it only covers server-side HTML sanitization).

I list some particularities of my app to have feedback on any point I forgot or a bad architecture pattern that would expose the app to XSS vulnerabilities.

Edit 2

I choose Erlend's answer as the best, however msoliman's one is excellent too, and is complementary to Erlend's answer.

Answer 1

While you are doing a good job here, I think you should consider this: Escaping data to avoid XSS needs to be context dependent. OWASP XSS prevention cheat sheet explains this in detail.

IMHO, when receiving data from the client, you should make sure data is valid according to the domain. This is what you are doing with route params. You expect it to be an int, and reject if it isn't. For other data types you should do the same thing. Is this a valid first name? (first names usually do not contain < or >). Is this a valid zip code? This will stop a lot of attacks, because attacks often contain characters that are not valid within the given context.

When it comes to stopping attacks, XSS, SQL injection etc. are all subclasses of the same problem. You have to escape the data when adding them to the HTML (or XML or SQL query etc.), and you need to escape for the given context. How to escape data is different depending on whether it is between tags, as an attribute value, within CSS etc.

By trying to sanitize things on the way in, you might end up in a situation where you discover that you santization function was not good enough, and you have partially/wrongfully sanitized data, and it will be a mess to fix.

Summarized:

a) Validate and reject according to domain on the way in

b) Perform context based escaping during output

Answer 2

You could sanitize the html in the client side .. Sanitize/Rewrite HTML on the Client Side

Also you could follow the following thread to check how to do in server side too for better security wises

Preventing XSS in Node.js / server side javascript