Hacker News Reader

Comment by jayar95 | Hacker News Reader

If security is a concern, this is probably a bad choice; this doesn't seem to be advertised as a bulletproof security solution to anything, rather a utility for small little one-off apps that might need _some_ backend functionality. Once you start adding features like file-uploading, youre obviously gonna want to pick a more robust option

View on HN

> If security is a concern

At the risk of being presumptuous... When is security ever not a concern?

Student projects

Conversely though - doesn't that lead to bad habits?

If security is taught at the student level, by the time they get to junior developer they'll have an understanding of it / do it automatically.

When you're learning, you need to also learn security implications of what you're writing. Insecure projects should never be allowed to pass.

I disagree somewhat. If the goal of a project is to teach a different skill and it may cause too much of a headache to add a real server this service might make sense. It’s like when you’re learning a new spoken language. It’s better to practice a breadth of situations and vocabularies and make mistakes (that get corrected over time) than to learn fewer things perfectly

Pretty sure student projects should teach you something other than `$ npm install`, no?

When I was a hiring manager and scoped out juniors from bootcamps I had a conversation with some candidates and they would say, "I built user registration and login". When I asked them to talk more about it they said, "well I installed auth0"... Any student project which doesn't teach them how something works is not really teaching anything of value, is it?

Expecting a student to learn how to code at all, not to mention code well, from an academic/bootcamp setting, is an expensive fool's errand for anyone that hires them.

Programming is not academic. It has more in common with plumbing and carpentry and electrician work: you learn only by doing, and you learn how to do it well by doing with critical supervision from a mentor.

That slight wobble in Earth's orbit we're experiencing, that's Dijkstra rolling in his grave.

All joking aside, programming should be treated a lot more like engineering and a lot less like craft. Yes, it does have aspects of both, but neglecting the engineering aspects of it is proving to be increasingly harmful to our end users.

> a lot more like engineering and a lot less like craft

I think the curve of diminishing returns plays an important role. A near hack job will often get you 90% there, in terms of fulfilling what was exactly requested. I don't think this is true for any other skillset. It's so easy to make something featureful and fragile in software. The time and cost above that can be very difficult to justify to customers/management.

In the words of a previous boss, after I pointed out we need more testing, "Everything is working, we'll fix the bugs as they come".

The difference between engineering and trade work is that trade work, like the jobs you mention, either follows a plan written by an engineer, or prescriptive standards designed by engineers (and usually certified by governing bodies of engineers). Prescriptive standards allow skipping all the engineering calculations as long as the guidelines are followed and tolerances respected.

Software development (and a lot of hardware development, to be fair) is unique in that doing it well requires functioning as both an engineer and a tradesperson. One's skill has to cover a wide section of the spectrum.

> When is security ever not a concern?

Internal applications where the entirety of the userbase are trusted employees. (Preferably, the userbase is small, too.)

Nobody’s going to bother finding vulnerabilities in an application where, if they break it, their own job gets harder.

I agree with GP. Security is always a concern. I too used to think as long as it's behind the firewall, or a local only exploit, it doesn't matter. But it always matters. Small apps become big apps. Small user bases large ones. Someone gets onto your internal network and then your small userbase app for trusted employees becomes a jumping off point, etc.

Your sort of thinking is how you end up with Yahoo levels of account leaks.

Security always matters.

I think your comment about scalability is accurate. Small apps become big apps, and small user bases get bigger. I’ve seen it happen — but I’m not going to think about scaling to thousands of users when I just need a small application to share with my team. If I spent five days building it to the utmost standards, instead of spending one day on something that solves a problem immediately, I’d be laughed at. It is the same with security.

> Your sort of thinking is how you end up with Yahoo levels of account leaks.

I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!

> Security always matters.

The first part of securing a system is to come up with your threat model, isn’t it?

> I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!

I'm completely sure that you're right. You know that would be irresponsible and reckless with lots of very sensitive data.

With that said, how sure can you be of every other person writing a simple, small, business app for just a handful of their coworkers? I've encountered some people doing exactly what you've described without the same level of cool-headed risk-weighing as you.

At some point you will be outcompeted by businesses where they don't sweat stuff like this.

One of the key functions of GDPR and CCPA and PIPEDA is to make many businesses consider what kind of liability might be attached to things they might otherwise opt to not sweat.

None of those apply to internal software that isn't used to store customer data.

I really hope you don't work for our infosec department!

Prototyping or proofs of concept

If you're ever running this, and you've left it open to a LAN or the internet, your entire system is vulnerable for use in whatever way someone wants. There are bots looking for stuff like this all the time.

Is this even a serious question?

Not everything runs online connected to the internet.

But almost everything does. Assumptions like this lead to ~40,000 unsecured MongoDB databases on the public internet [1]

1. https://www.information-age.com/major-security-alert-40000-m...

And printers. Although in the linked story the exploit already existed and the guy who did the printing sounds like basically a script-kiddie.

https://www.theverge.com/2018/11/30/18119576/pewdiepie-print...

You know it's always a concern, but context is everything.

> small little one-off apps that might need _some_ backend functionality

The security implications of serving a static website vs. a dynamic application that processes payment and queries the database are two different beasts

When all other layers are secure, like wearing a bulletproof west inside a bulletproof car inside a bunker that can withstand a nuclear blast. And add to that some security by obscurity, like a bunker in a secret location, only accessed via a tunnel.

That said, if security is top priority you also want to be ready if you get shot from within the car. But more importantly you need to define the most common scenarios and make sure you are protected from all of them. One scenario might be someone shooting you, but another scenario might be food poisoning which would require an additional, different solution.

>_some_ backend functionality

Famous last words.

Reply on news.ycombinator.com