undefined | Better HN

0 pointscoffeecoders3mo ago0 comments

Not quite. This isn’t saying React or Next.js are fundamentally insecure in general.

The problem is this specific "call whatever server code the client asks" pattern. Traditional APIs with defined endpoints don’t have that issue.

0 comments

j453mo ago

I’m not asking if it’s fundamentally insecure.

Architecturally there appears to be an increasingly insecure attack surface appearing in JavaScript at large, based on the insecurities in mandatory dependencies.

If the foundation and dependencies of react has vulnerabilities, react will have security issues indirectly and directly.

This explicit issue seems to be a head scratcher. How could something so basic exist for so long?

Again I ask about react and next.js from their perspective or position of leadership in the JavaScript ecosystem. I don’t think this is a standard anyone wants.

Could there be code reviews created for LLMs to search for issues once discovered in code?

IgorPartola3mo ago

To be fair, the huge JavaScript attack surface has ALWAYS been there. JavaScript runs in a really dynamic environment and everything from XSS-onwards has been fundamentally due to why you can do with the environment.

If you remember “mashups” these were basically just using the fact that you can load any code from any remote server and run it alongside your code and code from other servers while sharing credentials between all of them. But hey it is very useful to let Stripe run their stripe.js on your domain. And AdSense. And Mixpanel. And while we are at it let’s let npm install 1000 packages for a single dependency project. It’s bad.

alisonkisk3mo ago

It's essentially impossible to deploy a non trivial NodeJS (including NextJS, Vercel, React, etc) project without critical vulnerabilities that npm will warn explicitly warn you about but be unable to avoid due to dependency hell of many packages depending unmaintained garbage that pins vulnerable versions of other packages.

koakuma-chan3mo ago

You mean call whatever server action the client asks? I don't think having this vulnerability was intentional.

lionkor3mo ago

This is only really fine as long as you have extremely clearly, well defined actions. You need to verify that the request is sane, well-formed, and makes sense for the current context, at the very least.

koakuma-chan3mo ago

You would probably need to do the same if you were writing back-end in Go or something. I don't see how that is conceptually different.

1 more reply

j453mo ago

I don’t think I’ve heard of intentional vulnerabilities?

morshu90013mo ago

Log4j almost seemed like it

1 more reply

cluckindan3mo ago

xz?

j / k navigate · click thread line to collapse

0 comments

j453mo ago

I’m not asking if it’s fundamentally insecure.

Architecturally there appears to be an increasingly insecure attack surface appearing in JavaScript at large, based on the insecurities in mandatory dependencies.

If the foundation and dependencies of react has vulnerabilities, react will have security issues indirectly and directly.

This explicit issue seems to be a head scratcher. How could something so basic exist for so long?

Again I ask about react and next.js from their perspective or position of leadership in the JavaScript ecosystem. I don’t think this is a standard anyone wants.

Could there be code reviews created for LLMs to search for issues once discovered in code?

IgorPartola3mo ago

alisonkisk3mo ago

koakuma-chan3mo ago

You mean call whatever server action the client asks? I don't think having this vulnerability was intentional.

lionkor3mo ago

koakuma-chan3mo ago

You would probably need to do the same if you were writing back-end in Go or something. I don't see how that is conceptually different.

1 more reply

j453mo ago

I don’t think I’ve heard of intentional vulnerabilities?

morshu90013mo ago

Log4j almost seemed like it

1 more reply

cluckindan3mo ago

xz?

j / k navigate · click thread line to collapse