5 ms·

I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its

by troad 5mo ago

I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few times a year, if that. Combine with obvious basic security practices like pnpm cooldowns + no build scripts. When you upgrade a few times a year, and frontend vulns don't matter, there's really no limit to the cooldown you can set. 60 days, why not.

austin-cheney 5mo ago
If you serve any third party logic, such as advertisements, your code is just as potentially compromised.
- troad 5mo ago
  Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius. Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.
ZiiS 5mo ago
It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.
- troad 5mo ago
  Not likely to be a major risk if you update every few months, to some major version that's already over a month old.
- wavemode 5mo ago
  I would imagine it's the opposite. Most dev's machines can't query the prod database, for example, whereas a prod server can.
  - erikerikson 5mo ago
    Nope, they've been targeting credentials so they can deploy whatever they like into prod. They prefer the build machine with it's broader rights than the individual dev boxes.
    - deleted 5mo ago
      [deleted]
erikerikson 5mo ago
> compiled bundle Where does that compilation happen again? Not on the front end and it happens exactly where the exploits have been targeting (dev and build boxes).
- troad 5mo ago
  Hardly a factor when you're (deliberately) months behind.
mghackerlady 5mo ago
Also, I feel like a lot of fullstack JS is written by people who started with frontend JS and don't have nearly enough backend experience
- troad 5mo ago
  I came from systems programming, so I think half of what happens in JS is nuts.
  - mghackerlady 5mo ago
    A lot of JS is nuts, but most of its basic behaviour that makes it not a good backend language make it an alright scripting language for the web specifically. I wish we would've used something tcl-y instead though, it's much cleaner and the "everything is a string"-ness makes sense for a fundamentally text based medium (the web)
    - tardedmeme 5mo ago
      If you drop-in replaced JS today with Lua, you'd have a conceptually similar language with a lot of warts chopped off. Backend devs can just cope with 1-based indexing though.
- sph 5mo ago
  JS programmers today are the PHP programmers of 25 years ago. Remember how many SQL injection bugs there was at the time? Little Bobby Tables remembers. The standards haven't changed; for the vast majority of JS programmers, this is their first programming language and they have no solid foundation of architecture and security. So what you get are these overly enthusiastic newbies that want to share their latest achievement with the world (say, a function to left pad a string), and why not include a fancy post-install script with emojis that makes adoption even simpler for other complete noobs? And this is the result.
  - mghackerlady 5mo ago
    And before PHP it was Visual Basic, and COBOL even further back. I'm convinced trying to teach people to program without them understanding the basics of how computers work will lead to this.

by troad 5mo ago

austin-cheney 5mo ago

If you serve any third party logic, such as advertisements, your code is just as potentially compromised.

troad 5mo ago
Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius. Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.

ZiiS 5mo ago

It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.

troad 5mo ago
Not likely to be a major risk if you update every few months, to some major version that's already over a month old.
wavemode 5mo ago
I would imagine it's the opposite. Most dev's machines can't query the prod database, for example, whereas a prod server can.
- erikerikson 5mo ago
  Nope, they've been targeting credentials so they can deploy whatever they like into prod. They prefer the build machine with it's broader rights than the individual dev boxes.
  - deleted 5mo ago
    [deleted]

erikerikson 5mo ago

> compiled bundle Where does that compilation happen again? Not on the front end and it happens exactly where the exploits have been targeting (dev and build boxes).

troad 5mo ago
Hardly a factor when you're (deliberately) months behind.

mghackerlady 5mo ago

Also, I feel like a lot of fullstack JS is written by people who started with frontend JS and don't have nearly enough backend experience

troad 5mo ago
I came from systems programming, so I think half of what happens in JS is nuts.
- mghackerlady 5mo ago
  A lot of JS is nuts, but most of its basic behaviour that makes it not a good backend language make it an alright scripting language for the web specifically. I wish we would've used something tcl-y instead though, it's much cleaner and the "everything is a string"-ness makes sense for a fundamentally text based medium (the web)
  - tardedmeme 5mo ago
    If you drop-in replaced JS today with Lua, you'd have a conceptually similar language with a lot of warts chopped off. Backend devs can just cope with 1-based indexing though.
sph 5mo ago
JS programmers today are the PHP programmers of 25 years ago. Remember how many SQL injection bugs there was at the time? Little Bobby Tables remembers. The standards haven't changed; for the vast majority of JS programmers, this is their first programming language and they have no solid foundation of architecture and security. So what you get are these overly enthusiastic newbies that want to share their latest achievement with the world (say, a function to left pad a string), and why not include a fancy post-install script with emojis that makes adoption even simpler for other complete noobs? And this is the result.
- mghackerlady 5mo ago
  And before PHP it was Visual Basic, and COBOL even further back. I'm convinced trying to teach people to program without them understanding the basics of how computers work will lead to this.