lirantal

Last week I updated my article on this topic :-)
I've specifically extended on why the the base image recommendation should *not* be alpine but rather a supported slim version of Debian. You probably want to dive into that first best practice in the article but if this is the first time you're reading it and you are often tasked with building container images and Dockerfile then you definitely want to give this comprehensive article a visit.

My article on dependency confusion supply chain concerns is finally published 🚀

I'm pretty hopeful you'll pick up a few things you didn't know about open source security in there, including several practice tips on how to detect and avoid dependency confusion which is still largely happening throughout corporates.

Sure, sometimes vulnerabilities in a Docker base image are irrelevant. They might be low severity, or targeting things like a compiler which we won't be particularly using inside a running application.

Until they don't, and you end up having a Node.js docker application running in production and it's an actual severe issue in the container image that results in a remote reverse shell, and overall command injection vulnerability.

I wrote a thing 👋
Docker for Node.js developers 🔥
The naive way of building your own Docker Node.js web applications may come with many security risks. So, how do we make security an essential part of Docker for Node.js developers?
Step-by-step best walk-through inside ✨

What are typosquatting attacks and how do they impact open source developers? If you're a JavaScript developer then you should understand them and be conscious that you aren't mistakenly installing a package such as electron-native-notify - because hey, that's a malicious package! ☢️ https://snyk.io/blog/typosquatting-attacks/ #JavaScript #NodeJS #npm #Security

I did a Q&A interview with Ethan Arrowood about the Fastify NodeJS web application framework. We talked and discovered some interesting bits like his favorite features, what are some good signals for a health opensource project, and more.

🔥 What are the risks of command injections in NodeJS applications?

✅ Featuring a practical walk-through of an actual CVE for a NodeJS module which has a command injection vulnerability

I wrote about it here https://snyk.io/blog/command-injection/

Looking for the best ways to secure your React app? Then you’ve come to the right place!

I created this checklist of React security best practices to help you and your team find and fix security issues in your React applications. I’ll show you how to automatically test your React code for security-related errors and automatically fix them.

In this security article about prototype pollution vulnerabilities in Node.js command line libraries, Kirill builds a proof of concept vulnerable application and goes into details as to the concerns of such security issues.

Let's build a backdoor in a Node.js npm package because why not really? Ulises has a step by step code tour of building a malicious npm package and goes into the complexities of how would it work and how to take remote command and control over this.

If you run a website, whether this is a full-fledged SaaS web application or a small blog — built by Gatsby, WordPress, or an indie GitHub Pages setup — one of the key concerns you want to mitigate is security vulnerabilities.

A severe security vulnerability impacted all popular npm package managers: npm, yarn and pnpm and even triggered a release for Node.js 12.4.0. What is behind this vulnerability and why is it so important for us to understand? I wrote about it in a post that also explains how npm handles executables.

What risks are we introducing just by our choice for an image used in our Docker containers? Let's find out what it means for Node.js docker containers

finds publicly known security vulnerabilities in a website's frontend JavaScript libraries

Don't underestimate lockfiles as a vector of security weakness.
Lockfiles can be easily thought-of as just the mechanics of package manifests, however if not inspected carefully and using proper tools to investigate them, they could easily become an attack vector for outsiders to inject malicious packages.

kudos to Kirill from the security research team who worked on this discovery as well as providing the fixes (!) and many thanks and appreciation to the Sequelize project maintainers who worked with us on the responsible disclosure and promptly issued fixes to vulnerable versions where necessary.

How do you cope with the issues of libraries having security vulnerabilities but there's no fix yet? With open source packages this might even be more apparent than ever. Maintainer are rightfully not in any contract to provide you support, yet you rely on third-party software by volunteers.

In this piece I want to show you how we've adopted surgical patches to help remove this burden and risk from users.

I have a small serverless side-project that I'm hosting on AWS Lambda and I was keen on sharing my story of how I'm tracking security vulnerabilities for functions deployed to the cloud. Since that's quite different than containers or traditional application servers it may not be very obvious as to why we actually need to track them or how to do it.

This article is detailing the step by step journey I did for my personal side-project and why it's so important.

Serverless doesn't mean "less" security, instead we should fine-tune our focus area to security implications that accompany a serverless architecture and understand the relevant best practices to follow.

Affected versions of axios are vulnerable to Denial of Service (DoS) because content continues to be processed from requests even after maxContentLength is exceeded, causing increased I/O and CPU usage.

To minimize exposure, opt-in to create a dedicated user and a dedicated group in the Docker image for the application; use the USER directive in the Dockerfile to ensure the container runs the application with the least privileged access possible.

The Node.js runtime is known to have many strengths, but one of them, the single threaded Event Loop, can also be its weakest link if not used correctly. This happens more regularly than one might think.

Regular expression denial of service (ReDoS) attacks exploit the non-linear worst-case complexity vulnerabilities that some regex patterns can lead to. For a single-threaded runtime this could be devastating, and this is why Node.js is significantly affected by this type of vulnerability.

A Node.js express middleware that implements API versioning for route controllers

I published a thing about Consumer-Driven Contracts testing. Perhaps the most comprehensive guide on integration testing for API microservices in Node.js or in other words - How to avoid the pains of breaking your API for consumers!

Life is good! Or so I thought…
what would have happened had I slipped a change into the project’s package.json file but had forgotten to commit the lockfile along side of it?

A cheat sheet that focuses on npm security and productivity tips for both open source maintainers and developers.

Starting off with classic mistakes such as people adding their passwords to the npm packages they publish, importance of two-factor authentication (2FA), tokens in your CI and the value of running a local npm proxy like Verdaccio

Node.js CLI tool to visualize an aggregate list of your dependencies' licenses

Node.js library to convert unix or linux CRON syntax to Quartz Scheduler