CODEWITHSUNDEEP
javascriptnode.jsexpressmiddleware
Shashika Virajh
Shashika Virajh

Reputation: 9457

Node/Express security

Im working on my first node application. Now it is ready to deploy and I want secure my application. So I used these libraries to secure it.

import mongoSanitize from 'express-mongo-sanitize';
import helmet from 'helmet';
import xss from 'xss-clean';
import hpp from 'hpp';
import cors from 'cors';
import rateLimit from 'express-rate-limit';

What I want to know is, Am I duplicating things here? Do I have to use all these libraries? Do the libraries here do the same thing so that I can remove them to improve the performance of the app by removing unnecessary middlewares from the app?

Upvotes: 1

Views: 1601

Answers (1)

Brad
Brad

Reputation: 163272

You can't just pile on some "security" library and magically become "secure". Don't you think that if this were possible, all of these packages would be applied automatically, already?

Let's look at what these modules actually do...

express-mongo-sanitize

This module searches for any keys in objects that begin with a $ sign or contain a ., from req.body, req.query or req.params. It can then either:

  • completely remove these keys and associated data from the object, or
  • replace the prohibited characters with another allowed character.

This is (arguably) a really bad idea. If you were escaping things correctly for use in your queries in the first place, such a sanitizing function wouldn't need to exist. And then, you wouldn't have to worry about a module like this totally wrecking your data structure. Furthermore, if you did rely on this sort of library, you can be sure that there will be some way around it, as it isn't solving the fundamental problem... that mixing the contexts of data and commands is dangerous and error-prone.

helmet

Helmet is a collection of 14 smaller middleware functions that set HTTP response headers.

This package has a whole bunch of stuff, from HSTS to disabling caching. None of them are some sort of security silver bullet, as the author of this package cautions at the very top of the readme file:

It's not a silver bullet, but it can help!

You should understand what all these headers actually do so you can use the right ones. Additionally, much of this you'll want to apply at your web server (such as Nginx) rather than dealing with it in your application.

xss-clean

This will sanitize any data in req.body, req.query, and req.params. You can also access the API directly if you don't want to use as middleware.

Nothing says "security" like an NPM package with near-zero documentation that hasn't been touched in 4 years. It's really an awful idea to begin with though. You should be escaping data for the context of HTML only when you insert that data into HTML. If you do it early, you're just corrupting your data. Misunderstanding of this can actually lead you to future security problems, not to mention a mess of a broken application. (See also: The holy grail of cleaning input and output in php?)

hpp

Express middleware to protect against HTTP Parameter Pollution attacks

This module takes multiple query string variables and prevents them from coming back as an array. This is fine if that's what you want, but having multiple of the same key in the query string is intended, and well-documented behavior that your application can use. If this is a problem, you should actually fix your application rather than relying on this module to break the standard behavior.

cors

As @jfriend00 points out, the CORS library helps you add the appropriate response headers to enable cross-origin access to data. This can be secure and appropriate, but not something you probably want to enable by default.

express-rate-limit

Basic rate-limiting middleware for Express. Use to limit repeated requests to public APIs and/or endpoints such as password reset.

This can be useful, if you want rate limiting. I'd suggest doing this though at the web server level rather than messing with it in your application. There are efficient and fast modules/configurations for Nginx and similar, which are going to be able to handle this better than building it into every Node.js application you build.

TL;DR;

Understand what it is that you're protecting against, or you're absolutely doomed to be insecure no matter what modules you install. Security isn't some patch you install.

Upvotes: 13

Related Questions