5
8 Comments

How do you protect the singup-api against bots?

Let's say you run a multi-tenant application where you have separate databases, userpools for each client (for each singup-api call, these resources get called).

So your competitor decides to flood your signup-form with tons of requests? How do you go about protecting your signup-api from such a scenario?

I know there are several ways from using a captcha on signup form (least user-friendly) to complicated rules (limiting registration/ip, having a pay-wall/free-trial etc).

What mechanism are you using?

on July 25, 2020
  1. 3

    If it’s a huge ddos that you can’t handle at all then you need something like cloud flare.

    If it’s moderate traffic that’s hitting your database but your http server can otherwise handle, and assuming you’re sending an email verification email, then one way to mitigate this problem is to completely avoid hitting your database until you verify the email address. Basically, your registration form can bundle up the signup details in an encrypted object and send that to the supplied email address without checking any of the details. Your signup page needs to be static for this to work since a non static signup page is expensive to generate.

    You can achieve this by encoding all the signup data in an encrypted object, and emailing that object to the supplied address as a link. This needs to happen on the server side. It doesn’t stop them hitting the signup page but it reduces the cost to you. If you use a performant encryption scheme like Libsodium/nacl then this will use minimal CPU resources. The object should include an expiry time so that the ability to replay these messages is limited (you could also include a serial number etc but don’t hit your satabase)

    You encode this into a URL and email it without touching your database. Only after the user clicks on the link and sends the object back to you, do you decrypt the object (which is still fast) and check the expiry time. If the message is valid, only then do you check if the address is already registered and if so you can fail really quickly.

    The entire process basically uses a small amount of CPU and a single database read. It significantly increases the complexity of an attack on you since they now need to send an http request with a real email address, listen for the email and send the result -before you do anything at all other than a bit of http.

    You can then combine this with post-verification checks on the email domain name (eg rate limit based in the email domain) and some simple IP rate limits that are easy enough to do on the server side.

    Hope this helps

    Cheers

    1. 1

      This makes lot of sense. Thanks for taking time to reply.

  2. 2

    Currently, I'm using limiting IP mechanisms to fight bots. For some APIs, they are configured to only accept requests from a whitelisted host.

    Sometimes, I do have signups using fake email services. I haven't built the feature but have thought about reducing fake email signups. For example, create a blacklisted domain, then reject if someone uses it. Like this list of disposable domains on Github

    With bots that automate signups on client-side, ReCaptcha v3 is definitely helpful

  3. 2

    We use recaptcha on StatusGator and it solved all our bot problems.

    1. 1

      How would it work with APIs? For example apis used in iOS?

  4. 2

    We experienced this first hand when we did our soft launch. Within days, a malicious user started submitting fake email addresses by the hundreds with fresh proxies for each, effectively flooding the database at first.

    This became easier to block when we put the site behind CloudFlare and then added reCAPTCHA. The issue went away after that.

    1. 1

      This comment was deleted 6 years ago

  5. 1

    You can use ReCaptcha v3 which is invisible for non-malicious users

  6. 1

    I haven't had any issues with the API being hit directly, but like @justaDev I did have to add a captcha to the sign up form itself to prevent fake account creation.