[apsurd]

it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine.

that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages.

edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever.

i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.

[chuckadams]

SQL injection is prevented by using database APIs properly, not sanitizing. Put all the malicious SQL you want in a query string, if it's passed as a bound parameter to a prepared query, it's only ever going to be a plain string.

You might sanitize for different reasons like business logic, but if it's your first line of defense against sql injection, you're already on the losing side.

[slopinthebag]

I don't get your point, I'm not saying sanitising user input isn't important, I'm saying these JS frameworks are only concerned with server rendering and routing. They don't provide any tooling for databases like Rails or Laravel do.

[apsurd]

JS frameworks are very much in the "full-blown app" category.

As an example, the "react" is just a view layer is a purest pov, to me (or whatever the given framework in question is). Nextjs, Vercel, supabase, lovable, and so on down the line all empower millions of people to ship full-blown apps. We might get carried away with which specific layer is in question, but it doesn't matter if they're always used together to ship millions of (in)secure apps.