5 ms·

Your vanilla app will have the same vulnerabilities, but you just won't know, because there are not thousands of people checking your code constantly. Not knowi

Your vanilla app will have the same vulnerabilities, but you just won't know, because there are not thousands of people checking your code constantly. Not knowing, and not having vulnerabilities are two very different things.

8n4vidtmkvmk 2y ago
Having a very tiny attack surface helps. 30 lines of JS is unlikely to have a critical vulnerability compared to 100k lines of random libraries.
- threatofrain 2y ago
  Having a very tiny app helps. In 30 lines of JS I couldn't implement a small data structure. But if you're building a front-facing app for consumers then public opinion is the judge of whether your app is emotionally delightful (more important than useful).
Joeri 2y ago
I think a vanilla project will have fewer vulnerabilities, not more. Most of the vulnerabilities in frameworks are in the very complicated build tooling or deeply nested dependencies. A vanilla project doesn’t have that, so there are entire classes of vulnerabilities that don’t occur there. Vanilla does come with a higher risk of XSS, but basically all you need is a templating function that does XSS defense like lit-html and you’re good to go.
- Juliate 2y ago
  Yes. A higher risk of SQL injection too, also. Or of brute force attacks/scans, but those are often not managed at the app/framework level anyway.
  - Joeri 2y ago
    SQL injection will depend a lot on what backend language you’re working with. Most have platform database api’s that can do parameter binding.
  - norman784 2y ago
    I suppose that you are not writing your db driver from scratch and you are using a driver that was at least written in the last 10 years, so it will support for sure prepared statements and you will use it, that means no possibility of SQL injections.
devjab 2y ago
I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Even if you still use Node/Bun/Whatever as your core but then build your own app with no external dependencies you’re going to reduce the security risks you have greatly. This is if you’re using JS. If you’re building your application in something like GO only using the standard library and writing all the JS you use yourself, then you’ll have almost no external vulnerabilities. I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. The most known example is Log4j, but there have been many other examples. This is made even worse with how attacks are done today, which is largely automated. So if you use an extremely common technology which turns out to have vulnerabilities then you’re also going to be far more likely to be attacked.
- selfmodruntime 2y ago
  > I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Because it is not vetted. These dependencies are run through multiple checking tools day by day. You will get automated alerts for dependencies, which you can then easily patch. There is an entire industry behind checking for vulnerabilities in public libraries. The best incentive for something is and has always been money. You have neither of this if you roll your own entirely. > I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. This is a false equivalency. Log4j was found, publicly discussed and was subsequently patched.
  - Juliate 2y ago
    That depends a lot on how complex, large and critical your app is. And on the skills of the builder and the maintainer. The surface attack is considerably reduced if you do not rely on a large list of dependencies. Moreover, you do manage to know _better_ the ins and outs of each bit of your system (because you wrote it, and the whole surface has been walked on at least once). Unless you are of a specific interest to an attacker, not relying on external dependencies makes you less detectable as your app may not behave as scanner expect it to. It's a bit like comparing going on a trip by walking with one person you know well or with 100 people: you still get to make the trip, but, the delays, the risks, the provisions, the contingencies, the consequences of an incident are not really in the same scope. But for any large project involving more than 4/5 people, perhaps relying on no external dependencies may be a bit complex to manage in the long run.
austin-cheney 2y ago
Security by popularity is nonsense just the same as security by obfuscation.
- pelasaco 2y ago
  > Security by popularity is nonsense This is not what the author was suggesting. The author is suggesting that, more people using an open source piece of code has a higher chance to be revised which ultimately would lead to a better security.
  - austin-cheney 2y ago
    This argument comes up super frequently. Yes, more people actually reading the source code is better for identifying security vulnerabilities, but that almost never how it’s either articulated or implied. When most people make this argument the suggestion is that popular software must be more secure because somebody would have certainly identified and reported the vulnerability. That makes several assumptions not qualified by evidence. In other words it’s wishful thinking. As a case in point when I reported my first V8 defect it was around the time of Node 4.4. Chrome had been out for several years at that point with many millions of users. The defect I found was that V8 could not perform recursion using only function name. WTF. The problem was missing test cases, not a lack of eye balls.
    - diatone 2y ago
      To adjust an old joke about economics: “Two open source maintainers are walking along the street when one says: Look! A repo exposing an API allowing unprivileged deletion of users! The other replied: that vulnerability clearly cannot be real, as someone would have fixed it already.”
  - gessha 2y ago
    Who checks dependencies other than the author of the library ? The only time I check them is when they break and that's not a good thing. I see this argument as “it’s not my job” type of argument. Most of the time you just install and use. If I had infinite time, I’d do it because it’s fun but I don’t so I don’t. If there’s a trust chain and I know for sure certain libraries are reviewed I’d have a peace of mind. Alas, that’s not the case and we spend our days in back burner paranoia or blissful ignorance.

8n4vidtmkvmk 2y ago

Having a very tiny attack surface helps. 30 lines of JS is unlikely to have a critical vulnerability compared to 100k lines of random libraries.

threatofrain 2y ago
Having a very tiny app helps. In 30 lines of JS I couldn't implement a small data structure. But if you're building a front-facing app for consumers then public opinion is the judge of whether your app is emotionally delightful (more important than useful).

Joeri 2y ago

I think a vanilla project will have fewer vulnerabilities, not more. Most of the vulnerabilities in frameworks are in the very complicated build tooling or deeply nested dependencies. A vanilla project doesn’t have that, so there are entire classes of vulnerabilities that don’t occur there. Vanilla does come with a higher risk of XSS, but basically all you need is a templating function that does XSS defense like lit-html and you’re good to go.

Juliate 2y ago
Yes. A higher risk of SQL injection too, also. Or of brute force attacks/scans, but those are often not managed at the app/framework level anyway.
- Joeri 2y ago
  SQL injection will depend a lot on what backend language you’re working with. Most have platform database api’s that can do parameter binding.
- norman784 2y ago
  I suppose that you are not writing your db driver from scratch and you are using a driver that was at least written in the last 10 years, so it will support for sure prepared statements and you will use it, that means no possibility of SQL injections.

devjab 2y ago

I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Even if you still use Node/Bun/Whatever as your core but then build your own app with no external dependencies you’re going to reduce the security risks you have greatly. This is if you’re using JS. If you’re building your application in something like GO only using the standard library and writing all the JS you use yourself, then you’ll have almost no external vulnerabilities. I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. The most known example is Log4j, but there have been many other examples. This is made even worse with how attacks are done today, which is largely automated. So if you use an extremely common technology which turns out to have vulnerabilities then you’re also going to be far more likely to be attacked.

selfmodruntime 2y ago
> I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Because it is not vetted. These dependencies are run through multiple checking tools day by day. You will get automated alerts for dependencies, which you can then easily patch. There is an entire industry behind checking for vulnerabilities in public libraries. The best incentive for something is and has always been money. You have neither of this if you roll your own entirely. > I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. This is a false equivalency. Log4j was found, publicly discussed and was subsequently patched.
- Juliate 2y ago
  That depends a lot on how complex, large and critical your app is. And on the skills of the builder and the maintainer. The surface attack is considerably reduced if you do not rely on a large list of dependencies. Moreover, you do manage to know _better_ the ins and outs of each bit of your system (because you wrote it, and the whole surface has been walked on at least once). Unless you are of a specific interest to an attacker, not relying on external dependencies makes you less detectable as your app may not behave as scanner expect it to. It's a bit like comparing going on a trip by walking with one person you know well or with 100 people: you still get to make the trip, but, the delays, the risks, the provisions, the contingencies, the consequences of an incident are not really in the same scope. But for any large project involving more than 4/5 people, perhaps relying on no external dependencies may be a bit complex to manage in the long run.

austin-cheney 2y ago

Security by popularity is nonsense just the same as security by obfuscation.

pelasaco 2y ago
> Security by popularity is nonsense This is not what the author was suggesting. The author is suggesting that, more people using an open source piece of code has a higher chance to be revised which ultimately would lead to a better security.
- austin-cheney 2y ago
  This argument comes up super frequently. Yes, more people actually reading the source code is better for identifying security vulnerabilities, but that almost never how it’s either articulated or implied. When most people make this argument the suggestion is that popular software must be more secure because somebody would have certainly identified and reported the vulnerability. That makes several assumptions not qualified by evidence. In other words it’s wishful thinking. As a case in point when I reported my first V8 defect it was around the time of Node 4.4. Chrome had been out for several years at that point with many millions of users. The defect I found was that V8 could not perform recursion using only function name. WTF. The problem was missing test cases, not a lack of eye balls.
  - diatone 2y ago
    To adjust an old joke about economics: “Two open source maintainers are walking along the street when one says: Look! A repo exposing an API allowing unprivileged deletion of users! The other replied: that vulnerability clearly cannot be real, as someone would have fixed it already.”
- gessha 2y ago
  Who checks dependencies other than the author of the library ? The only time I check them is when they break and that's not a good thing. I see this argument as “it’s not my job” type of argument. Most of the time you just install and use. If I had infinite time, I’d do it because it’s fun but I don’t so I don’t. If there’s a trust chain and I know for sure certain libraries are reviewed I’d have a peace of mind. Alas, that’s not the case and we spend our days in back burner paranoia or blissful ignorance.