Hacker News Reader

Comment by Vates | Hacker News Reader

When one OAuth token can compromise dev tools, CI pipeline, secrets and deployment simultaneously, something architectural has gone wrong. Vercel have had React2Shell (CVSS 10), the middleware bypass (CVSS 9.1), and now this, all within 12 months.

At what point do we start asking questions about the concentration of trust in the web ecosystem?

It's funny that at the engineering level we are continuously grilled in interviews about the single responsibility principle, meanwhile the industry's business model is to undermine the entirety of web standards and consolidate the web stack into a CLI.

View on HN

Coming from a company that makes infrastructure out of a view layer / vDOM library - I think anyone relying on Vercel has only themselves to blame.

That and also the CEO posting a photo of him posing with a war criminal. Using let alone relying on Vercel baffles me.

Which one? There's so many these days I've lost track.

It feels like the political forces underpinning the software industry are coming to light but it seems like there are two opposing forces now instead of just one.

It's interesting that Next is becoming so popular when LLMs supposedly have a capability to work with all these other frameworks that don't create a dependency on something like Vercel.

You don't have to use Vercel to run NextJS though

You have no idea how indifferent security officers can be-even when you point out critical issues. The other day, we flagged that a customer’s database had users with excessive privileges. Their only question: “Can this be exploited from the outside?”

No, but most breaches today come from compromised internal accounts that are then used to break everything.

What's the problem to have local API connected in HTTP? We are within the enterprise network.

And that's how I passed for a annoying "PM". With half of the program management complaining that I was slowing down things until 6m later, the head of risk management told them to get lost.

> the head of risk management told them to get lost

That's why it's important to org-chart engineer for security, if a company is really serious.

The problem with security is that often it's cheaper to deal with the bad outcome than to prevent it. Actually getting security right is very expensive because it requires virtually every engineer to have some security awareness, and engineers who can be trusted with that tend to be difficult to find. Meanwhile if you have a security incident you say "sorry", maybe you pay a small fine, and a month later everyone had already moved on.

This misalignment is especially bad at startups. In my experience security is only prioritized when driven by the customer and is largely a performative box checking exercise.

The answer is Yes, this can be exploited from the outside by taking over dev machines and using their access.

If you answer No and complain that it’s not taken seriously, it’s at least in part because you didn’t show the risk clearly.

maybe a dumb idea , but maybe using some kind of one time token access would resolve ? some physical keycard would guarantee this to not happen at all right ?

There is always a disgruntled employee:) They will do anything to do maximum harm

JavaScript living only as a built artifact in an s3 bucket makes for a much simpler life.

until someone starts a botnet making your S3 invoice to $10k. Pay per usage is always a liability.

It is horrendous that aws doesnt allow any usage limits.

The whole hiring system needs to be eradicated. You get grilled by incompetents, who ask one question, never ask back when you provide something that is debatable, they give zero feedback and then you see what kind of errors these "elitist" engineers make. Burn it to the ground.

Best hiring systems I saw were when actual engineers hiring for their team were doing the bulk. You get a gauge of what you can expect and them too.

Polite reminder as to why Domain Driven Design is super-important. It makes more sense to spend 80% on DDD initially and then only 20% on the code (80-20 rule) vs the other way round. Or you will end up in a clusterfuck like this.

Domain Driven Design is something that I have only come to know with full understanding at my current job and oh my it is useful. It's not a silver bullet, but for complex domains it's a must.

GitHub looking awful quiet in the corner on the room there

three critical vulns in 12 months is a pattern not a coincidence. the SRP point is sharp - we interview engineers on isolation principles then build platforms that are the opposite of that.

Reply on news.ycombinator.com