@joeri,
Incorrect, you should always have Server Side protection/validation/encoding/decoding etc to ensure that the data that’s being sent or received by the client is as you require/is to the specification you impose.

You are right to say there is no single way to encode, the dev must come up with the correct method to suite the data.

You are also (sort of) right to say that having multiple methods is an overhead. A simple condition check (server side) is all that’s needed to determine if the data being sent from the client is to spec.

Remember, you should always have both client and server side protection/validation/encoding/decoding etc in applications. The client can “NEVER” be trusted, therefore the last bastion of protection and control is the server.

@joeri We're looking at having some kind of global config that will htmlEncode <stuff>, the things that immediately spring to mind are grids/trees/combos, however it's difficult to know where to draw the line for this (think templates, renderTpl, Element.update).

Twitter - @evantrimboli
Former Sencha framework engineer, available for consulting.
As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

You are right to say there is no single way to encode, the dev must come up with the correct method to suite the data.

Please don't confuse data with context. You encode to suit the context. The context is separate from the type of data. For example, I may show a user's first and last name in a tooltip (HTML attribute) and in a panel (HTML element). In that case I have to encode the same data in two different ways. According to you I would be sending the same data twice from server to client. That's a hack in my opinion.

I come from the perspective of having shared web services between ExtJS and Android / iOS. The web service has to return data in unencoded form for the mobile platforms. In this example I would have to send the data in three different formats. Ugly, ugly, ugly. And completely unnecessary, because...

Originally Posted by MrSparks

Remember, you should always have both client and server side protection/validation/encoding/decoding etc in applications. The client can “NEVER” be trusted, therefore the last bastion of protection and control is the server.

The Server is under your control, the Client is not.

That is true but irrelevant in this discussion. You say that encoding on the server is safer because the client cannot be trusted. What is to prevent a user from having an ExtJS override that automatically de-encodes the data coming back from your web service before it gets injected into the page? Bingo: "XSS attack". But that's not what XSS is.

XSS protection is about protecting your user against hidden page modification by a stranger. The only "trust" you need to have here is that your or your user control all changes to the page. In other words, you need to trust that the ExtJS code you're sending isn't modified in transit, and that no other code gets injected into the page. Encoding on the client can guarantee that just as easily (in fact more easily) as encoding on the server.

What you are right on is that the client cannot be trusted to send valid data back to the server, which is why the server always must do input validation and authentication / authorization checks. But that's an orthogonal issue from XSS, which is best solved on the client.

XSS protection is about protecting your user against hidden page modification by a stranger.

That’s an Interesting way of looking at it but it's placing the trust on the user, which of course you can never do. Fundamentally if the sever side controls have been developed correctly, there is no way a stranger could have injected malicious content into the data in the first place. Of course there’s always man in the middle attacks but that’s a different problem.

Am I right in thinking that your issue is, you are potentially connecting to untrusted sources of data (web services etc provided by someone else) and you are worried that someone might have compromised that data?

If that’s the case you will need to add a server side layer for XSS protection between EXT JS and the untrusted source.

You've listed server and client side code. Are you just talking about 1 or both?

I'm talking about the interaction between client and server.

I'm trying to get my point across that encoding on the server doesn't offer more protection against XSS than encoding on the client. Any scenario you think up that involves someone hacking the client-side encoding can equally apply to a situation where the encoding happens server-side.

If you're encoding on the server your code can be made as secure as when you're encoding on the client. But I maintain that it's the wrong place because its further removed from the rendering code, and the rendering code is the only code that really knows which encoding context is the current context. The risk for security issues is bigger, not smaller, if you're encoding on the server.