3 ms·

Frontend security issues do exist and can be big problems. Especially in SPA designs where the frontend runs a massive in-memory database of an entire applicati

Frontend security issues do exist and can be big problems. Especially in SPA designs where the frontend runs a massive in-memory database of an entire application state. (As many of them do, especially if you are using things like frontend routing and ad hoc backend DB querying as both example libraries are about.) .NET has a security support policy that LTS versions (currently even version numbers) are supported for a couple of years and non-LTS versions (currently odd version numbers) for a year after they've been released. A lot of frontend packages don't have the maintenance budget to offer support plans on anything but the most recent major version (in part because many of them are open source and low contributor count; their own problems for the ecosystem). Don't discount security/support maintenance concerns in the frontend. Also, yes, it is a problem that many frontend packages in the ecosystem don't have maintenance policies as strong as the best backends.

froddd 2y ago
On such popular and packages, one should reasonably expect security holes to be found and made public with relatively little delay. At that point, upgrading becomes relevant.
nosefurhairdo 2y ago
The packages referenced in this article do not have known security vulnerabilities in the latest minor/patch versions of their previous majors. So the author is still complaining about an unnecessary update.
littlecranky67 2y ago
> Frontend security issues do exist and can be big problems. Citation needed. > Especially in SPA designs where the frontend runs a massive in-memory database of an entire application state How is that more relevant for security issues? Common Frontend Security issues are traditionally xss, csrf, token/session theft etc. Lot of those attack vectors have been severely weakened with modern browser security settings (Content-Security-Policy, HttpOnly cookies, SameSite=strict etc.). Eager to hear how a view router (wouter) or a server-state-management system (react-query) in the FE are likely to have security wholes in that field.
- WorldMaker 2y ago
  Two big easy and obvious ones missing from your list: - Query injection (always a threat to any query library) - RegEx DDoS (always a threat to routers because all most routers are is a miserable pile of RegExes and because route writers don't like RegExes directly, often include DSL compilers to RegExes, which can lead to their own exploits) JS is a Turing complete language and though it is often run in a sometimes strict sandbox mathematicians have now proven there's a "0-Day" sandbox break in the Universal Turing Machine and that it is likely a corollary/relative of the Halting Problem. Sure, modern browsers absolutely have a ton of security settings and improve every day on that, but browsers aren't perfect (mathematically can't be perfect, according to our best understanding). JS is still a complete programming language with everything that implies about exploits and bugs and timing attacks and disclosure leaks. "severely weakened" is not "the threat doesn't exist" and certainly not "the threat isn't worth worrying about, it is fine to leave bugs unpatched". It certainly means you can take a measured approach to how you prioritize unpatched bugs, but a general malaise sense of lack of priority in frontend issues is what contributes to why frontend libraries don't have the same backwards compatibility rules or long-term security maintenance habits as many backend systems. As an industry we are really bad about looking down on frontend as a second-class environment when it is one of the largest percentages of all program code running on the average user's machines this decade. I could keep listing CVEs for days, and then still have weeks of lecture topics about how npm has one of the biggest ecosystems for supply chain attacks right now (and those are an active and ongoing threat). I understand the lack of perceived priority and I appreciate that not everyone has the same level of "full stack paranoia" that I do.
  - littlecranky67 2y ago
    > RegEx DDoS you don't seem to have any understanding what SPAs are. There is no server-side code in your SPA, all code is run on the users browser. If you do any sort of DoS, you will bring down the users browser, not the server hosting the SPA. How is that a feasible attack vector? > Query Injection Again, not SPA relevant. What is injected? How do you even inject that code into the browser of a user, if you do not have access to the server-side end of the application? XSS, as I said, is mostly mitigated in SPAs that use CSP.

froddd 2y ago

On such popular and packages, one should reasonably expect security holes to be found and made public with relatively little delay. At that point, upgrading becomes relevant.

nosefurhairdo 2y ago

The packages referenced in this article do not have known security vulnerabilities in the latest minor/patch versions of their previous majors. So the author is still complaining about an unnecessary update.

littlecranky67 2y ago

> Frontend security issues do exist and can be big problems. Citation needed. > Especially in SPA designs where the frontend runs a massive in-memory database of an entire application state How is that more relevant for security issues? Common Frontend Security issues are traditionally xss, csrf, token/session theft etc. Lot of those attack vectors have been severely weakened with modern browser security settings (Content-Security-Policy, HttpOnly cookies, SameSite=strict etc.). Eager to hear how a view router (wouter) or a server-state-management system (react-query) in the FE are likely to have security wholes in that field.

WorldMaker 2y ago
Two big easy and obvious ones missing from your list: - Query injection (always a threat to any query library) - RegEx DDoS (always a threat to routers because all most routers are is a miserable pile of RegExes and because route writers don't like RegExes directly, often include DSL compilers to RegExes, which can lead to their own exploits) JS is a Turing complete language and though it is often run in a sometimes strict sandbox mathematicians have now proven there's a "0-Day" sandbox break in the Universal Turing Machine and that it is likely a corollary/relative of the Halting Problem. Sure, modern browsers absolutely have a ton of security settings and improve every day on that, but browsers aren't perfect (mathematically can't be perfect, according to our best understanding). JS is still a complete programming language with everything that implies about exploits and bugs and timing attacks and disclosure leaks. "severely weakened" is not "the threat doesn't exist" and certainly not "the threat isn't worth worrying about, it is fine to leave bugs unpatched". It certainly means you can take a measured approach to how you prioritize unpatched bugs, but a general malaise sense of lack of priority in frontend issues is what contributes to why frontend libraries don't have the same backwards compatibility rules or long-term security maintenance habits as many backend systems. As an industry we are really bad about looking down on frontend as a second-class environment when it is one of the largest percentages of all program code running on the average user's machines this decade. I could keep listing CVEs for days, and then still have weeks of lecture topics about how npm has one of the biggest ecosystems for supply chain attacks right now (and those are an active and ongoing threat). I understand the lack of perceived priority and I appreciate that not everyone has the same level of "full stack paranoia" that I do.
- littlecranky67 2y ago
  > RegEx DDoS you don't seem to have any understanding what SPAs are. There is no server-side code in your SPA, all code is run on the users browser. If you do any sort of DoS, you will bring down the users browser, not the server hosting the SPA. How is that a feasible attack vector? > Query Injection Again, not SPA relevant. What is injected? How do you even inject that code into the browser of a user, if you do not have access to the server-side end of the application? XSS, as I said, is mostly mitigated in SPAs that use CSP.