dependency management
4 articles with this tag
Express (Node.js) security — the defenses you add yourself
Express is minimalist — it ships almost no security features by default, so the defenses are ones the developer adds. The essentials: (1) security headers (helmet-style), (2) input validation and sanitization, (3) authorization scoped to the owner, not just authentication, (4) rate limiting (brute-force / DoS), (5) dependency (npm) CVE monitoring and fast patching. Plus SSRF protection for outbound URL fetches and secrets kept in env, out of code. The freedom of a minimal framework comes with the responsibility to defend.
Next.js security — Server Actions, environment variables, and dependency CVEs
Next.js ships fairly safe defaults, but incidents happen at the server/client boundary. The big three: (1) environment-variable exposure (misusing NEXT_PUBLIC_ or passing server-only secrets to the client), (2) missing authorization in Server Actions / Route Handlers (authenticated but no owner scope), and (3) known dependency CVEs (including framework core RCE — judge by the running version and patch fast). Defenses: keep secrets server-only, mind the boundary, authorize in every action, machine-monitor dependency CVEs.
Ruby on Rails security — Strong Parameters, authorization, and gem CVEs
Rails ships conventions and safe defaults (CSRF protection, Strong Parameters, an ORM) and is solid used correctly. But incidents come from operations. The big three: (1) over-permissive Strong Parameters allowing Mass Assignment (overwriting is_admin, etc.), (2) thin authorization (login = authentication, but no owner scope), (3) known gem (dependency) CVEs. Plus SQLi via string interpolation in where, dangerous dynamic methods (send/constantize), and leaked credentials/secret_key_base. Defenses: tighten permit, make authorization explicit, monitor gem CVEs.
Spring Boot security — dependency CVEs, Actuator exposure, and authorization
Spring (Spring Boot) is an enterprise staple. Incident types: (1) known dependency CVEs (a widely-inherited foundation flaw like Log4Shell — judge by the running version and patch fast), (2) exposed management/diagnostic endpoints like Actuator (info leak / operation), (3) missing Spring Security authorization (authenticated but weak permission checks), (4) unsafe deserialization. Defenses: machine-monitor dependency CVEs and patch fast, lock down Actuator/management surfaces, make authorization explicit, don't deserialize untrusted data.