HTTP REST Security

A web application like ours will make direct HTTP requests to a web server in order to get and put data. Pretty standard stuff, and of course one wants a good deal of security in place to make sure that people only read and write data that is theirs. This is where the rub comes in.

Partial REST Security

The issue is that a call like GET /api/users/123/jobs can be secured quite nicely. After all, the only users who should be able to access this are an admin and user 123. But, this illustrates the big hole.

We can only secure those URLs which require authentication.

Uh, well, of course you can only secure a web application after authentication. But, what of those URLs that must be accessed prior to authentication. During the sign in process, or the sign up process there are various REST endpoints just sitting there for someone to brute-force attack. I'm not suggesting that someone will be able to compromise user data, but they could probe enough to determine whether a user has an account, or create a DDOS attack.

Examples of these "unprotected" urls are:

1. GET /api/users/byemail/:email

   This is a url our signup process uses to be clever when integrating sign in and sign up in a single fluid process, but it also allows any hacker to probe our system for viable user accounts.

2. POST /api/users/signup

   A hacker could hit this endpoint with a series of requests which will cause us to store partial user records in our database and send out a massive number of spam messages to unsuspecting users.

3. POST /api/users/:id/verify/:token

   This open url will allow the hacker to brute force attack a newly signed up user's email verification token.

Dealing With It

This isn't a new or unique problem. Most web sites have these issues, and I would bet that most of them are doing nothing to detect or prevent malicious use. In fact, there is precious little we can do about the problem that can prevent a determined individual from accessing a url that our own application must access.

To protect #2 above, we can use a captcha to prove the user is human. This also has the problem of driving down our signup conversions. I would rather use a captcha honeypot and prove the user is a computer instead of disadvantaging my users.

Rate Limiting

This isn't implemented yet, but rate-limiting requests seems to be a good way to prevent against malicious users, and it only needs to be implemented on these few urls.