3 ms·

Not really?

by speedgoose 5y ago

Not really?

zach_garwood 5y ago
Kinda really. This entire class of security lapse can be avoided by not building a js app on the client.
- gcommer 5y ago
  Plenty of server-rendered apps have been caught putting private data in responses. In this very same comment section people have mentioned the story of a state website that included teacher SSN's in hidden fields[1], and OJFord shared a story of a server that included a full env var dump in error messages[2]. This sort of thing happens all the time to all sorts of services. Rather than just blaming JS, it's far more productive to think of technical controls that could catch this. For example Taint Checking[3] or scanning server responses for API keys. [1]: https://news.ycombinator.com/item?id=31026374 https://news.ycombinator.com/item?id=31026374 [2]: https://news.ycombinator.com/item?id=31026415 https://news.ycombinator.com/item?id=31026415 [3]: https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking
- deleted 5y ago
  [deleted]
- speedgoose 5y ago
  Yes I guess if you don’t build apps you have fewer security issues.
louissan 5y ago
The reason I react (no pun intended haha) this way is because I have seen with my own eyes blue chip (US -- is that the right expression for "company name known quite literally the world over"?) companies doing exactly these sort of things. I have seen the plastering of webpacked-gulpified-obfuscated-minified-hoistpropified-younamedifiedit mind-blowing amounts of Javascript to create the latest "cool" app. I have seen web pages best described as "this webpage is so heavy not even light can escape it". The (not full) cast, not in order of appearance: . 5MB+ of Javascript (not kidding) -- _after_ the above . gazillions of HTTP requests . internal data bled through to the outside world (not always problematic from a security point of view, but one may as well: 1) save on the bytes 2) not give malicious ideas to you-know-who) . code coverage is inversely proportional: with grand score hovering around 3-5%..... End result: . from inside: a bloated over-engineered chaos (see entry: "Big Ball of Mud") . from outside: catastrophic load times of around 35 seconds w/o a primed cache. Talk about the latest shiny new "single page application"..... Granted, it's not always like that! :)

Not really?

zach_garwood 5y ago

Kinda really. This entire class of security lapse can be avoided by not building a js app on the client.

gcommer 5y ago
Plenty of server-rendered apps have been caught putting private data in responses. In this very same comment section people have mentioned the story of a state website that included teacher SSN's in hidden fields[1], and OJFord shared a story of a server that included a full env var dump in error messages[2]. This sort of thing happens all the time to all sorts of services. Rather than just blaming JS, it's far more productive to think of technical controls that could catch this. For example Taint Checking[3] or scanning server responses for API keys. [1]: https://news.ycombinator.com/item?id=31026374 https://news.ycombinator.com/item?id=31026374 [2]: https://news.ycombinator.com/item?id=31026415 https://news.ycombinator.com/item?id=31026415 [3]: https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking
deleted 5y ago
[deleted]
speedgoose 5y ago
Yes I guess if you don’t build apps you have fewer security issues.

louissan 5y ago

The reason I react (no pun intended haha) this way is because I have seen with my own eyes blue chip (US -- is that the right expression for "company name known quite literally the world over"?) companies doing exactly these sort of things. I have seen the plastering of webpacked-gulpified-obfuscated-minified-hoistpropified-younamedifiedit mind-blowing amounts of Javascript to create the latest "cool" app. I have seen web pages best described as "this webpage is so heavy not even light can escape it". The (not full) cast, not in order of appearance: . 5MB+ of Javascript (not kidding) -- _after_ the above . gazillions of HTTP requests . internal data bled through to the outside world (not always problematic from a security point of view, but one may as well: 1) save on the bytes 2) not give malicious ideas to you-know-who) . code coverage is inversely proportional: with grand score hovering around 3-5%..... End result: . from inside: a bloated over-engineered chaos (see entry: "Big Ball of Mud") . from outside: catastrophic load times of around 35 seconds w/o a primed cache. Talk about the latest shiny new "single page application"..... Granted, it's not always like that! :)