Recently we had a discussion about the security of a mobile app we are working on. The security team requested that if a user is blocked (due to many failed login attempts), then the back-end should return the date/time the block will be lifted, so that the mobile app will internally block all outgoing API calls until that date/time.

The reason quoted is that a user or a large number of users could attempt to do a 'fake login' to perform some sort of DDoS attack, and a way to stop that attack would be to make the app block these attempts if the user is blocked.

Does this make any sense? I can't find any arguments with or against this logic. but i personally don't see the benefit because a DDoS attack requires a very large number of requests per second.

  • 1
    wrt, 'so that the mobile app will internally block all outgoing API calls until that date/time' - if an attacker is going to try to DDOS your API endpoint, they are not going to use your app to do it. They are going to use a rented botnet, or something similar.
    – mti2935
    Nov 10, 2021 at 13:27

1 Answer 1


When securing a back end, it is useless to do any assumption on the origin of the requests. Said differently, you must be prepared to received forged requests that the frond end could not send.

That means that asking the app to stop sending request is definitely not a way to secure the back end.

On the other hand, having the app being aware that it is blocked for failed login attempts could be used to display a user message explaining the reason why they cannot use the app, and when they could expect to be able to use it again. So it could certainly provide a better user experience. But it is unrelated to security.

You must log in to answer this question.

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