NodeJS security cheat sheet

``` bouncer.blocked = function (req, res, next, remaining) { res.send(429, "Too many requests have been made. Please wait " + remaining/1000 + " seconds."); }; // route to protect app.post("/login", bouncer.block, function(req, res) { if (LoginFailed){ } else { bouncer.reset( req ); } }); ```

So I went to check the library to understand why. The library hasn't been updated since 5 years!

https://www.npmjs.com/package/express-bouncer

I'm not sure if these security measures are up to date.

Flat promise chains aren't fully general (you'll need a lot of trivial helper functions to do anything other than sequence of single operations). This is fine because you shouldn't be using nontrivial .then()s outside of utility code.

Alternate advice: always use async/await for asynchronous control flow.

Request limits, toobusy, and several other pieces of advice assume you're throwing a single node process on the internet directly. Do not do this, you probably want at least an nginx or other battle-ready front end proxy, and probably want a CDN and/or load-balancer too. Configure these correctly to not send overlarge, weird, slowloris, etc., requests through to the node processes.

The thing about express letting API attackers create exotic objects is genuinely scary, and if true makes me want to not use express anymore or at least install a middleware to drop requests that try it.

Describing anti-XSS measures as 'escaping' is a little questionable, you should be using proper tools for generating machine-readable information, not string concatenation or (shudder) interpolation. Build a DOM, convert it to text, send it out unmodified.

IP level rate limiting simply doesn't work, at least not in the trivial "just use bouncer" way described.

It's unexplained what you could possibly use object property descriptors for to obtain security benefits. They are not, in general, a security perimeter. If attacker is running code in your context, attacker has won.

uncaughtException is difficult to use correctly, error prone, and has little to offer in general. The default behavior does the right thing. uncaughtExceptionMonitor lets you do a little extra logging before crashing if you like and is less of a footgun.

Much of the rest of the advice is generic web application security recommendations.

However, I'm a bit confused by the first one, "use flat Promise chains": it doesn't feel like a question about security, but more about code readability. While a good practice to use promises (and maybe async/await instead of then), it feels much like saying use switch instead of if/then/else because it's less prone to errors.

  const fs = require('fs');
  fs.readFile('/file.txt', (err, data) => {
    // perform actions on file content
    fs.unlink('/file.txt', (err) => {
      if (err) throw err;
    });
  });

  const fs = require('fs/promises');
  const data = await fs.readFile('/file.txt');
  try {
    // Do something with the data
  } finally {
    await fs.unlink('/file.txt');
  }

When everything is urgent, nothing is.

> The most common protection against these attacks is to implement account lockout, which prevents any more login attempts for a period after a certain number of failed logins.

Imho account lockout has a huge downside. It reveals the username to attackers, because only on correct usernames the account lockout hooks in. I just would keep it silent and throttle the requests down on any false attemp.

Edit: “posted when” because I don’t know if this is outdated advice, but async/await introduced after Promise standardization addresses the problem.