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