Web Programming TutorialsHow to Keep Apps Secure in Express.js

How to Keep Apps Secure in Express.js

Security is one of those really important technology topics that it seems like people are always talking about. The threat of a cyber-attack is kind of always in our minds in this day and age of identity and data theft, and security topics are widely discussed in the greater conversation of technological development and intellectual property rights. Paradoxically, especially in the open-source sort of sector of web development, security procedures are one of the last parts of a development project, and they’re often taken for granted to a degree that leaves them open to attack from a lot of malicious programs and users.

In this article, we’re going to talk about how you can improve your web application’s security, and in particular, how you can achieve that within Express.js. Express.js is a JavaScript framework that’s built on top of Node.js, which means that it can handle both front and back end development. It’s one of the first JavaScript frameworks out there and it’s currently used to Netflix for their web development, among others.

Importance of security
For various reasons, JavaScript has kind of a bad name in security, especially on its user end. Shoring up security measures on the app and server sides of things can really help, in this regard, and it’s an important move anyway. One of the general concerns that this article will talk about a lot is protecting middleware, because it’s the kind of the go-between in the server-client relationship and it spends the most time in the most contact with other sensitive parts of the server base. Protecting your files and your client’s information is all part of being a professional server host, and allowing malware attacks or data theft on your watch, so to speak, can hurt your reputation quite a bit.

Don’t run as root
This is a topic that relates to upholding best practices. Typically, the best way to organize running privileges is that a server should be run at the least amount of privilege that’s necessary and no more. However, it’s easy to get lazy and assign things to run as root. Unfortunately, this leaves them open to attack, because if someone co-opts their process, then you’ll be stuck in a situation where malware has root access to the entire superstructure of your app.

Input validationInput validation

By itself, Express.js doesn’t sanitize or validate any data input when it comes through a query or a body-parser. One of the simplest and first lines of defense for your app is to add a regular expression checker that can parse through inputs in order to see if anything malicious pops up. It’s worth noting that input that seems benign, can later become malicious, so this is obviously not the only security measure you’re going to want to take. It is an important and easy one to implement all the same.

Remove X-Powered By
X-Powered By is a standard security feature that comes with Express.js. Unfortunately, it also broadcasts to everyone that your app is running X-Powered By and that can make it very easy for an attacker to create a profile of your security features. This can then lead them to an exploit more quickly. The irony isn’t lost on most developers, I’m sure.

Process permissions
We’ve already talked about how it’s a bad idea to run services in the root directory. One alternative to a process that might otherwise require root access is to drop privileges after binding a process to a particular port, rather than giving the process root access outright. This is a little safer and is generally a preferable method to using root access.


Generic cookie name
This is another topic along the lines of not broadcasting what security service you’re using. You can use generic names for the cookies you’re employing, which means that anyone looking at them won’t see them as different or more important from one another. This makes it harder for an attack to identify a point of access or even tell what kind of technology you’re using.

Cross-site request forgeryCross-site request forgery

Cross-site request forgery, or CSRF is a piece of middleware that matches incoming values and requests with their intended functions. Obvious, this is a critical piece of software, and it’s what I was talking about earlier when I mentioned that middleware touches more pieces of the app than anything else will. Something you can do to increase the security of this process is to install a checker into the CSRF which can parse out good data from possibly malicious data.

ReDoS attack
ReDoS stands for ‘regular expression denial of service.’ It’s kind of an old hat security bypass that turns the way regular expression works against itself by executing code in an event loop that it can’t get out of, which lets malicious users do all kinds of things. Fortunately, the solutions to this are pretty easy – you can review your code for patterns that will cause this kind of thing, and you can make sure not to ever use user-uploaded inputs as regular expression inputs.

HTTP security headersHTTP security headers

Our final topic here is a piece of free middleware called Helmet. It’s available on GitHub, and it basically is a collection of security middleware that can greatly improve your security, especially in the critical middleware section. Helmet has a ton of features that I’d recommend you look up for yourself.

Hopefully, these pieces of information will help you increase your net security and continue to uphold the best practices out there. Security is important, after all, and its


Please enter your comment!
Please enter your name here

Exclusive content

- Advertisement -

Latest article


More article

- Advertisement -Eduonix Blog