[Matumio]

> Anything exiting the user's agent must be cleaned.

We all agree on that part. What's worrying here is the mentality that, once the server-side has been secured, the client can do whatever. It can be manipulated anyway, so it does not matter for security if it does validation or not.

This is wrong. As a user, I don't care if an attacker has manipulated my data on the client or on the server. As a site owner you are responsible for delivering a secure client.

Yes we should define our terms. The first term we need to define is "security". From the comments here, I'm starting to think people define it as "RCE on the server". That's a rather narrow view.

> step us all through this scenario where a secure server side does not save the day

Back to the example: maybe you're building a chat tool, and it has this sentiment-feature to help with moderation. At the very least, this bug could hide offensive content from a moderator. But you are calling POST to "/api/sentiment/" with untrusted text that can leak into other parts of the request. I haven't done the analysis, but maybe an additional form field could be set, say "learnAsPositive=true"? Or maybe you have some questionable "not a security problem" API design that re-uses the same POST endpoint for multiple things, and you could set "blockUser=true" and control the user name, or moderators can edit the message text. Or maybe it wasn't a sentiment endpoint but something more important, and the untrusted text could be the name of another user.

[rendall]

You say a lot of true things that aren't related to what I said and asked. No one said "the client can do whatever". No one reasonable says that.

> you are calling POST to "/api/sentiment/" with untrusted text that can leak into other parts of the request

Could you expand on this? What does 'leak into other parts of the request' mean?

> Or maybe you have some questionable "not a security problem" API design that re-uses the same POST endpoint for multiple things, and you could set "blockUser=true" and control the user name, or moderators can edit the message text.

Again, this sounds like a server-side problem and bad coding practices. If someone is allowing such things to happen, then the user has worse problems than the dev not formatting their data properly.

The OP's contention was that (pseudocode)

  fetch({body:stringFromOutsideTheFunction})

is inherently a security risk and that the methods outlined would protect against the security risk.

I don't need to flog this horse. OP probably got a lot more attention for this article than he's used to. I wish he would at least mention that security must be done on the server-side, but whatever.

I'd like to point out that the concerns you do specifically have, that bad client-side code could lead to the user being fooled in some way is definitely true. I don't see how the example can naturally lead to that, but as I said, I'll let this go. However, one thing you can do to protect your users is to make sure that the server that serves the javascript has a content-security-policy response header, which would prevent XSS attacks. This will prevent altered code from loading in the browser. Read more about it here: https://content-security-policy.com/

Even more basic, everyone should be serving over https://. Those certificates used to be expensive, but now they are free or low-cost. This will encrypt the request/response traffic between your server and the user. More details here: https://letsencrypt.org/

[Matumio]

The original code was attempting to set a single form field named "text", while actually allowing that text to control the whole form being submitted.

This is a security risk, because form requests can mix trusted with untrusted inputs. (Trusted: e.g. the action selected from a drop-down. Untrusted: e.g. another user's text or name, or an entity name decoded from the initial URL.)

So, sticking with the "moderation tool" example, you could make a moderator execute an unintended moderation action when they interact with your carefully-crafted username.

The article showed that a piece of vulnerable frontend code was generated. Most commenters instantly dismissed that as an irrelevant concern and instead talked about securing the backend. Yes, you need to secure the backend. You need to protect against XSS. Neither of those fixes the problem that was shown in the code.

[rendall]

> The article showed that a piece of vulnerable frontend code was generated.

The article didn't show anything. It just asserted it.

All right. This is over.

I'd be delighted if at least one of you two could present a coding example that, when run, demonstrates an actual problem that needs to be dealt with.

Declare victory if you must, but if your next response is anything other than example code that, when run, demonstrates the problem, it will be clear to everyone that you guys don't know what you're talking about.

Sorry to be so blunt but there's only so many ways to ask how it's a problem before it's clear there is no real answer.

TL;DR: coding example or GTFO