Methods of preventing SPAM with an API - AngularJS Website Contact Form

Question

I'm exploring AngularJS and ran into an interesting question. If I develop an API to power my AngularJS website it would include public facing items such as a Contact Form. Assume an API method exists /api/contact and a POST request will create a new contact form entry.

How can we prevent a spammer from using an automated script to to create millions of entries? An API token wont really work here as we dont need to identify the user at this stage.

Some ideas that we considered:

1. Restrict number of creates per IP address
2. Handshake with the server - but nothing to stop to spammer replicating this.

I assume this is an issue that is commonly solved - can anyone point me in the direction of (Or share) some resource on the subject?

• Chris Cirefice: IP rate limiting isn't super effective against spammers, who often use botnets. Take a look this question which has some more ideas. Usually it's a combination of these techniques... that said, you should use unique API keys for any applications that can access your API. If your API is public and you don't require API keys, IP limiting and rate limiting are probably your best bets, with a configurable blacklist. How you implement any of this is platform-specific, and you didn't specify your backend.
• LiamB: Hi @Chris - Thanks for the link and info. The backend is C# (So Web-API).

Answer 1

I guess the common solution is a capatcha.

In your case you seem to have an odd set of restrictions

• you provide an API for presumably automated use. so you don't want to force human interaction
• you want to restrict each client to a rate limit
• you don't want clients to have to sign up/auth

my Suggestion is that you force the client to acknowledge the response with a computationally slow to generate reply before you process the request.

This will allow you to rate limit the clients by delaying your ack request and prevent multiple simultaneous requests from the same client, by forcing the computationally hard ack reply. perhaps bcrypt or some other slow hash? (mine a bitcoin!?)

However, it would be more usual to implement a signup/auth procedure which you can then use to identify individual clients

• LiamB: The examples I gave are not restrictions but Ideas to combat the issue i've presented. If using a front end framework to build a website we dont always know who a client is. It could be a contact form or a feedback form. These are not unusual things.
• Ewan: contact and feedback forms use capatchas to prevent spam. why is this unsuitable for your senario?