4 ms·

Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your da

Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your data. Almost all issues should be handled by your backend. Most cases where it becomes an issue is when people drop security best practices falsely believing their frontend/client validation is a security layer. Anybody thinking updating your frontend solves your security issues has deeper problems.

WD-42 2y ago
> Rarely do security issues come from directly as a result of your choice of frontend/client framework Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.
- Jcampuzano2 2y ago
  Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
  - regularfry 2y ago
    Can you server-side render Vue? If you answer "yes" then it has exactly the same type of back-end security concerns that Next has by way of it rendering React.
wavemode 2y ago
Doesn't matter, a security update is a security update. So, especially when you work in a larger company, you end up having strict compliance requirements to keep things up to date. I'm as annoyed by it as the next guy. The supposed vulnerabilities are almost never actually relevant for frontend code, and rather assume that you are running Node as a web server. It's just one of those weird things that has resulted from how the JavaScript ecosystem has centralized around using node for everything (i.e. building frontend code as well as executing backend code - even though the two have kind of nothing to do with each other.)
- jamesfinlayson 2y ago
  Yep, I've been in a big company with a dedicated security team and it was easier to just patch the dependency than to try and argue that we weren't vulnerable (otherwise it would probably go on some risk register and be re-raised again in a few months time).
zelphirkalt 2y ago
About having other problems, I think you are right. However, often it is the frontend engineers pushing for using more frontend frameworks on the server side as well, and then implementing business logic there, not merely presentation, using arguments like "then we can have a mono repo for all the things and have type checks for frontend and backend" or "all in on language!" and suddenly you got into that situation.

WD-42 2y ago

> Rarely do security issues come from directly as a result of your choice of frontend/client framework Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.

Jcampuzano2 2y ago
Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
- regularfry 2y ago
  Can you server-side render Vue? If you answer "yes" then it has exactly the same type of back-end security concerns that Next has by way of it rendering React.

wavemode 2y ago

Doesn't matter, a security update is a security update. So, especially when you work in a larger company, you end up having strict compliance requirements to keep things up to date. I'm as annoyed by it as the next guy. The supposed vulnerabilities are almost never actually relevant for frontend code, and rather assume that you are running Node as a web server. It's just one of those weird things that has resulted from how the JavaScript ecosystem has centralized around using node for everything (i.e. building frontend code as well as executing backend code - even though the two have kind of nothing to do with each other.)

jamesfinlayson 2y ago
Yep, I've been in a big company with a dedicated security team and it was easier to just patch the dependency than to try and argue that we weren't vulnerable (otherwise it would probably go on some risk register and be re-raised again in a few months time).

zelphirkalt 2y ago

About having other problems, I think you are right. However, often it is the frontend engineers pushing for using more frontend frameworks on the server side as well, and then implementing business logic there, not merely presentation, using arguments like "then we can have a mono repo for all the things and have type checks for frontend and backend" or "all in on language!" and suddenly you got into that situation.