Encrypt/sign a client-to-API request?

Question

We are building a JSON API on top of our Ruby on Rails Web application, using JSONAPI::Resources to expose endpoints and Doorkeeper to handle user authentication.

Most of our API endpoints will be exposed only to authenticated users, and Doorkeeper will probably do a great job at enforcing that. But we still have a couple endpoints that will not be authenticated: sign up, login, account confirmation, and maybe a couple others.

I am worried that letting those API endpoints completely open will expose us to attacks, in the form of spamming new accounts for example.

1. Maybe I am worrying more than necessary? Do APIs usually let this kind of endpoint unsecure, and add prevention systems like throttling?
2. If not, is signing (or encrypting) my requests before sending them to the API server the right approach?
3. And if that's so, do you have any recommendation, or preferred approach, in doing so?

I tried to Google keywords like "rails API sign request" or "rails api encrypt request", but I'm not sure the results are pertinent, or which one would be recommended.

The first clients that will talk to this API will be Android then iOS applications, and we might add in the future client-side web applications (at the moment, our web application is monolithic and does not use the API).

Answer 1

Signing is pointless when you don't have a public key of the signer. You can't validate the signature anyway, so an attacker who wants to spam you with new accounts could just send a bogus signature. There are more efficient measures you can take like captchas or IP-based throttling.

Encryption, on the other hand, is never a bad idea. "Sign up" and "Log in" require exchange of sensitive information, so they should be encrypted. Also, in the age of data-mining everything can be sensitive information, including that John Smith looked at the profile of user 29252 on example.com at 2015-08-19 17:02:03. So even seemingly harmless information should be encrypted whenever feasible. Making your whole website - both API and static content - https-only or at least https-capable is never wrong.