SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.
There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface.
The choices related to displaying appropriate elements based on current user's role that's tied to entire logic of the app has literally zero to do with security.
No, the whole point of client-side rendering is to apply parasitic computing and offload the server by having the client perform work it can thus saving the bandwith and compute power.
Next benefit is application that's "snappy" and works well, which is what almost never happens sadly.
> that’s why you have JWTs and stuff like that.
No, you don't have JWT and "stuff like that" because of this. JWT is for offloading databases so you don't have to talk to a DB on every request since you can verify the token via signature check and thus implement distributed services that don't have to talk to central authority to authorize a request.
> where state is able to be maintained per user usually up by the same thread on the same physical server
And now you're trying to sound smart by adding servers and "threads". I've a feeling you're pulling my leg right now so I'll excuse myself since you started spouting absolute nonsense.
Concerning JWT, I think we were talking past each other as I was referring to a session-less Authentication scheme, which is more or less what you describe.
Finally, there’s no reason why the server can’t render JavaScript as well other parts of the page. In effect, if the server wanted to, it could render of a reactive version or an angular version depending on a variable. Can the client do that?
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.
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.
Everything rendered by the server has this potential as it must be deserialized by the browser.
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.
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.