I've been desperately trying to find a simple method of securing my API but still haven't found one that works. Unlike a lot RESTful APIs my API doesn't need user logins, tokens that expire, or other complex (though very secure) authentication methods, which makes most of the tutorials out there unusable.

The only requirement I have is that a POST request to log a record to my database on one route should be protected while a GET request to access records on that same route should be unprotected. The clients that are logging records are trusted and I would provide their credentials privately.

I've tried using this basic authentication method here:

var basicAuth = require('basic-auth');

var auth = function (req, res, next) {
  function unauthorized(res) {
    res.set('WWW-Authenticate', 'Basic realm=Authorization Required');
    return res.send(401);

  var user = basicAuth(req);

  if (!user || !user.name || !user.pass) {
    return unauthorized(res);

  if (user.name === 'foo' && user.pass === 'bar') {
    return next();
  } else {
    return unauthorized(res);

But the POST requests still worked when I used the wrong username and password.

I really don't know what to look for anymore, as I thought basic authentication like that would work.

EDIT: Managed to get this working after changing a couple of things after app.post, which I had overlooked.

  • Are you decoding the base64? I'm not sure how node.js implements authentication, but this might help: stackoverflow.com/questions/5951552/…. Just remember to use SSL, since HTTP Basic auth sends the username and password in base64 - trivial to decode. HTTP Digest is slightly better, but still crackable if sent without SSL and intercepted on the line.
    – datu-puti
    Jul 17, 2016 at 0:45
  • Thanks for your comment @elBradford. I'll definitely make sure I use SSL, thanks for the tip. Do you know of any good resources on implementing SSL? I think I might of gotten the basic auth to work (finally) after changing a couple of things in my server.js file that I'd overlooked. Jul 17, 2016 at 1:17
  • You'll need to configure your server for SSL and you'll need to purchase a SSL certificate from a trusted CA. A google search will turn up a bunch. I personally use Cloudflare for my SSL, which is free.
    – datu-puti
    Jul 17, 2016 at 1:20
  • 5
    Hey Andy. You seem to have solved the issue. I encourage you to write your own answer and accept it
    – GnP
    Sep 3, 2016 at 14:58
  • If you use Cloudflare, you need to make sure that the only source your server accepts connections from is Cloudflare. Other than that, it is a great and inexpensive way to add an encrypted route. You can also look at StartSSL and LetsEncrypt, both have free certs available. I use Cloudflare in front of all my servers. It regularly blocks known attacks as well. Sep 12, 2016 at 9:09

1 Answer 1


If you are not logging the RESTful GET that queries the data in your database and that data is intended to be public, then you can expose an HTTP GET and use the security built into the web server to keep harm from occurring during that operation.

For the RESTful POST, use TLS, the contemporary of SSL, but don't implement it yourself. You can set up an HTTPS POST on any modern web server with ease. Help desk support for installing the server-side certificate is usually supported by the CA. Because people all over the world implement HTTPS POSTs every day, the support for that operation makes it easier to set up and maintain than doing something simple that's actually secure.

What you coded is not secure, which you may not think is important.

To exercise due diligence in answering your question, be warned that giving people credentials over the phone or on a piece of paper is not secure without employing a secure protocol such as HTTPS. Relying on testing the value of a credential on the server leaves a gaping security hole that can lead to consequences you may have overlooked.

Attackers can easily identify the password on route and then wreck havoc on your client/customer/visitor's account and data. Even if the data is not business critical, unprotected writes might end badly. Someone could, for any number of reasons, place child porn or some military secret in your database, which you intend to leave open to the public. You wouldn't be able to prove that you or one of the trusted users didn't put it there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .