I see a lot of comments here like “this is just standard XSS” and I think that misses the bigger point (even if the author failed to properly articulate it). Th

I see a lot of comments here like “this is just standard XSS” and I think that misses the bigger point (even if the author failed to properly articulate it). The real problem here is making assumptions that then are broken. “Reflecting user input back to the user in a basic server side app? Just output encode it, now no XSS/html injection!” That makes assumptions about how the outputed user input will be used and appear in the markup. As soon as the reality changes (that output is now input into a client-side interpretation environment) the code has a vuln. This is important lesson to learn and it doesn’t matter what JavaScript framework or backend framework is being used: when you change assumptions you need to review any security decisions that were made on those assumptions. (This is also a solid example why output encoding alone isn’t sufficient to protect against XSS, Because output encoding makes assumptions about how the output is being used. Input validation is key and should be the primary way to protect against most injection attacks, followed by various types of output encoding or parameterization)