Hacker News Reader

Comment by tptacek | Hacker News Reader

In practice, XSS is largely mooted by the rise of front-end frameworks like React, Vue, and Angular, which are the modern norm for delivering UI (I don't think we have a single client that uses serverside-templated-HTML anymore), and the front-end framework approach is better than the Rails/Django approach; I'm very unlikely to find XSS in a simple React app, but not at all unlikely to find it in a Rails app, because people always dip out of the XSS protection to do programmatic tags.

View on HN

I think making the mistake of "unscoped find" that "atom_enger" was referring to is just as easy a mistake to make when writing a REST backend (to support a SPA front-end framework) as when using a traditional non-SPA web framework.

It's tempting, when writing a REST backend, to respond to e.g. "PUT /message/:id" by just executing "UPDATE ... WHERE message_id=?" from the parameter, without checking that that message belonged to the user whose credentials have been used to access the call.

That's possible with a non-SPA web framework, and it's also possible when writing REST backends.

Authz bugs are the most common bugs in every application, and no framework has a particular edge on stamping them out. I'm just responding to the claim about Rails having a security edge due to XSS protection, which it does not; in fact, it's become somewhat the opposite.

> I'm very unlikely to find XSS in a simple React app

I do offensive security. A lot of developers are ignorant of when/how React apps tend to be XSS vulnerable. Since it has a reputation as being 'safe' from XSS, devs often assume it's just something they don't have to worry about.

This has led to a small renaissance of XSS bug bounties on sites like hackerone, where you see a lot of specialists who just go around finding obvious, common XSS vulns in eg Angular apps.

I do offensive security. My direct experience, in my audit workload of web applications, which I've had pretty steadily (with some short gaps) since 2005, is that XSS vulnerabilities are far rarer in React applications (regardless of backend) than they are in Rails apps. It's not hard to see why: Rails begs you to disable XSS protection to get anything interesting done in HTML (basically, any time you dip out of Erb or Haml), there aren't a similar number of use cases for overriding React's control of the DOM (because the whole point of React is to give you safe control of the DOM), and when you do, in React, you do it (almost all of the time) with "dangerouslySetInnerHtml" (though this holds just as true with Vue and "v-html".

It's not my argument that there's no XSS in React apps. I've definitely found React XSS. But I assume any Rails app I test will have it somewhere, and, based on experience, I do not have that assumption about React applications.

I completely agree with your overall point, I was just making an aside about the tendency of more inherently secure systems to sometimes lead to dev laziness. The same thing can happen to Rust devs, but I wouldn't argue that it isn't way more secure generally than C.

Reply on news.ycombinator.com