5 ms·

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser whic

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unless you are fully aware of this. SPA doesn't have this problem as it will generally insert DB data into the DOM as text, no possibility of escape or execution by potentially malicious database entries. Not that you can't have issues in an SPA, but you have to do work to bring them about.

lolinder 3y ago
This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP `<?= ?>` tag directly, I have an XSS vulnerability. If I use Laravel with Blade templates [0], I don't. You're not saved from XSS by virtue of using JavaScript to render your code, you're saved from XSS by using a framework that escapes everything by default. Whether that framework builds the escaped HTML on the client or the server is immaterial. [0] https://laravel.com/docs/10.x/blade#displaying-data https://laravel.com/docs/10.x/blade#displaying-data
- BackBlast 3y ago
  You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential. Everything rendered by the server has this potential as it must be deserialized by the browser.
  - lolinder 3y ago
    > No SPA frameworks do this by default. No, but I've definitely seen bespoke, hand-rolled frontend code do it. You can't select SPA frameworks as representative of frontend rendering but look only at hand-rolled PHP from 2002 for backend rendering. No major SSR framework is XSS-vulnerable by default. Whether you're using Rails, Laravel, Spring, ASP.NET, Phoenix, or whatever, every template engine escapes your strings unless you opt-in with something like Rails's `html_safe`, and they have for over a decade. Unless you've built your own SSR framework by hand with raw string interpolation, the "easy" way to do things is also the right way, just as it is in React.
    - BackBlast 3y ago
      > No, but I've definitely seen bespoke, hand-rolled frontend code do it, and that's what you're comparing SPAs to on the server side. Yes, congratulations, you pointed out that you can hang yourself either way. That wasn't my point and I acknowledged as much in the first post. One has an unsanitized escape free method and the other does not.
- water9 3y ago
  Except what happens when react as the vulnerability you get attacked with everybody else with zero days… security through obscurity should be incorporated into any well multilayer defense. Make it not worth their time
water9 3y ago
We’re talking about where dynamic variables get populated either on the client side or the browser side. If you put invalid input, it doesn’t matter what side it gets surrendered on. Input validation and rendering are separate issues

lolinder 3y ago

This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP `<?= ?>` tag directly, I have an XSS vulnerability. If I use Laravel with Blade templates [0], I don't. You're not saved from XSS by virtue of using JavaScript to render your code, you're saved from XSS by using a framework that escapes everything by default. Whether that framework builds the escaped HTML on the client or the server is immaterial. [0] https://laravel.com/docs/10.x/blade#displaying-data https://laravel.com/docs/10.x/blade#displaying-data

BackBlast 3y ago
You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential. Everything rendered by the server has this potential as it must be deserialized by the browser.
- lolinder 3y ago
  > No SPA frameworks do this by default. No, but I've definitely seen bespoke, hand-rolled frontend code do it. You can't select SPA frameworks as representative of frontend rendering but look only at hand-rolled PHP from 2002 for backend rendering. No major SSR framework is XSS-vulnerable by default. Whether you're using Rails, Laravel, Spring, ASP.NET, Phoenix, or whatever, every template engine escapes your strings unless you opt-in with something like Rails's `html_safe`, and they have for over a decade. Unless you've built your own SSR framework by hand with raw string interpolation, the "easy" way to do things is also the right way, just as it is in React.
  - BackBlast 3y ago
    > No, but I've definitely seen bespoke, hand-rolled frontend code do it, and that's what you're comparing SPAs to on the server side. Yes, congratulations, you pointed out that you can hang yourself either way. That wasn't my point and I acknowledged as much in the first post. One has an unsanitized escape free method and the other does not.
water9 3y ago
Except what happens when react as the vulnerability you get attacked with everybody else with zero days… security through obscurity should be incorporated into any well multilayer defense. Make it not worth their time

water9 3y ago

We’re talking about where dynamic variables get populated either on the client side or the browser side. If you put invalid input, it doesn’t matter what side it gets surrendered on. Input validation and rendering are separate issues