Recent searches
Search options
Administered by:
Looking into the current state-of-the-art for #NodeJS security and I'm kind of baffled by how primitive it is compared to browsers.
* No #TrustedTypes.
* No `SafeHtml`.
* No #ContentSecurityPolicy.
* No permission abstractions.
* Not even a way to ban `eval()`.
Best thing I've found is `--frozen-intrinsics`, which is interesting, and I don't think there's a browser equivalent. You still have to freeze `globalThis` though to get much value out of it.
https://nodejs.org/en/docs/guides/security/#monkey-patching-cwe-349
There are also some interesting security policies, which look like they have a lot of potential. However they're all experimental right now and seem focused on code integrity.
https://nodejs.org/api/permissions.html
This this really the state-of-the-art for #Node security right now? Am I missing something?
@develwithoutacause genuinely don’t think Node is capable of delivering the kinds of changes needed to fix its own ecosystem.
For such a long time JS has been the only game in town when it comes to building for the web and the difficulties of language interop were always incredibly frustrating which created a situation where JS started becoming a pretty normal decision for backends.
I wish Google had properly invested in gRPC-web both at a protocol and tooling level because it was one of the few things that probably had the chance to solve it. That didn’t happen though unfortunately.
But looking just over the horizon at things like WASM (especially with things like garbage collection, WASI and it’s emerging component model) we are starting to see a world where containing rather than expanding use of JS is not only possible but probably sensible.
When it comes to serialisation if gRPC-web isn’t going to take off there appears to be a sensible path forward through things like CBOR and it’s own data definition language. We are just missing the surrounding tooling to provide a protoc like equivalent.
But knowing all of this I am extremely hesitant to start building anything new in JS in general let alone Node. Still lots and lots of cases where it’s one of the only sensible choices though sadly but I wish we would build more tooling around changing that future so we can finally retire it in the not too distant future.
@develwithoutacause I mention gRPC-web only because I think cross language interop was so painful that it forced many teams to adopt Node as the reasonable choice for a backend despite all its other flaws.
If we had a better choice rather than manually serialising untyped JSON data structures across multiple languages (of which gRPC is one potential solution) we would see a much smaller adoption of Node which has a lot of meaningful security issues built into its very core that are going to be very difficult to fix from its non existent idea of permissions through to its supply chain issues.
I guess the argument I am making is that it sounds like it would be a better use of time to build reliable standards based solutions for building client / server web apps rather than continually putting bandaids on Node because that’s the most convenient DX for a lot of teams right now.
@develwithoutacause@techhub.social@mdh I can definitely see the argument that better #RPC technologies would reduce the desire for the client and the server to be the same language. Though in my experience I don't think I've ever seen shared logic in the API layer beyond #TypeScript types.
The environments are so different between the browser and Node that you have to really go out of your way to write portable #JavaScript.
Server-side rendering is the killer feature which usually shares code between the frontend and backend. If we could do that without either:
1) forcing the client JS to run on the server or
2) duplicating the rendering logic on the server
then users would have a lot more freedom to pick their preferred server language and ecosystem. #HydroActive does this.
Even if that was super successful, I doubt it would meaningfully reduce the developers using Node. JavaScript os just too big and developers don't want to context switch between different languages IMHO.
@develwithoutacause thanks for the video and thoughtful comment looking forward to checking it out