Security tutorial with Node.js

Security is a very important issue today, if you have come to this practical tutorial it is probably because you are concerned about the level of security and reliability of your programs. Keep reading to learn how to increase the security of your own App.

Let's get started and secure our app with Node.js using proper coding, tools, and trading habits!

1. Applying secure encryption forms

• First: avoid using eval

You may not know this information, but eval it can open your application for code injection attacks. Try not to use it, but if you have to, never inject non-validated user input into eval.

Eval isn't the only one to avoid for this: deep down, each of the following expressions uses eval:

setInterval (String, 2)
setTimeout (String, 2)
new Function (String)

• Second: try to always use the instruction 'use strict'

With 'use strict' you can choose to use a restricted JavaScript "variable". This variable removes some silent errors and discards them all the time.

'use strict' delete Object.prototype // TypeError var obj = {a: 1, a: 2} // syntax error

• Third: try to handle mistakes with extreme care

During different error scenarios, your application can lose sensitive data about the underlying infrastructure, such as: X-Powered-By: Express.

Stack traces are not treated as vulnerabilities by themselves, but they often reveal information that may be of interest to an attacker. Providing debugging information as a result of operations that fail is considered bad practice. You should always register them, but never show them to users.

• Fourth: Try to make a static analysis from your database

Static analysis of your application's database code can detect many errors. For that we suggest using ESLint with the standard code style.

Running your services in production safely

Using the proper code style is not enough to efficiently protect Node.js applications, you also need to be careful how you run your services in production.

• Fifth: avoid running your processes with superuser rights

Unfortunately, we see that this case happens a lot: developers are running their Node.js application with rights to Super useras they want it to be heard on port 80 or 443.

This is so wrong. In the event of an error or bug, your process can crash the entire system, as it has credentials to do anything.

Instead, what you can do is configure an HTTP server or proxy to forward the requests. It can be nginx or Apache.

• Sixth: configure the headers Required HTTP

There are some security-related HTTP headers that your site should set. These headers are:

• Strict-Transport-Security: This enforces secure connections (HTTP over SSL / TLS) to the server.
• X-Frame-Options: provides you with clickjacking protection
• X-XSS-Protection: You can enable the built-in XSS (cross-site scripting) filter in the latest web browsers.
• X-Content-Type-Options: this prevents browsers from sniffing out a response away from the declared content type.
• The content security policy prevents a wide range of attacks, including cross-site scripting and other cross-site injections.

In Node.js it is easy to configure them using the Helmet module:

var express = require ('express') var helmet = require ('helmet') var app = express () app.use (helmet ())

Helmet is also available for Koa: koa-helmet.

• Seventh: carry out a proper session management

The following list of brands must be established for each cookie:

1. secure:  this attribute tells the browser to only send the cookie if the request is being sent over HTTPS.
2. HttpOnlyly: This attribute is used to help prevent attacks such as cross-scripting, as it does not allow access to the cookie through JavaScript.

• Eighth: Establishment of cookie application environment

1. domain: This attribute is used to compare with the domain of the server where the URL is being requested. If the domain matches or is a subdomain, the path attribute will be checked next.
2. path: In addition to the domain, you can specify the URL path for which the cookie is valid. If the domain and path match, then the cookie will be sent on request.
3. expires: This attribute is used to set persistent cookies since the cookie does not expire until the set date is exceeded.

In Node.js you can easily create this cookie using the cookie package. Again, this is pretty low so you'll probably end up using a wrap, like the cookie session.

var cookieSession = require ('cookie-session') var express = require ('express') var app = express () app.use (cookieSession ({name: 'session', keys: [process.env.COOKIE_KEY1, process. env.COOKIE_KEY2]})) app.use (function (req, res, next) {var n = req.session.views || 0 req.session.views = n ++ res.end (n + 'views')}) app.listen (3000)

Consider the tools to use

Congratulations, you are almost at the end of the article! If you've followed this tutorial and performed the above steps thoroughly and to the letter, you only have one area to cover in terms of Node.js security. Let's dive into using the right tools to look for module vulnerabilities!

• Ninth: search vulnerabilities with Retire.js

The objective of Remove.js is to help you detect the use of versions of modules with known vulnerabilities.

Just install with:

npm install -g remove

After that, run it with the command withdraw will look for vulnerabilities in the directory node_modules. (Also note that remove.js not only works with node modules but also with front-end libraries).

• Tenth: audit your modules with the Node CLI security platform

nsp is the main command line interface for the Node security platform. Allows you to audit a file package.json or npm-shrinkwrap.json against the NSP API to check for vulnerable modules.

npm install nsp --global # From inside your project directory nsp check

Node.js security isn't a big deal after all, right? I hope that you have found these rules useful and necessary to secure your Node.js applications, and that you follow them in the future as security is part of your job. Congratulations!