Users may find themselves locked out of an account if they unsuccessfully attempt to log in too many times in a short amount of time. This occurs when a website has login rate limiting in place.

• This precaution exists, not to frustrate users who have forgotten their passwords, but to block brute force attacks in which a bot tries thousands of different passwords in order to guess the correct one and break into the account. If a bot can only make 3 or 4 login attempts an hour, then such an attack is statistically unlikely to be successful.

Rate limiting on a login page can be applied according to the IP address of the user trying to log in, or according to the user's username. Ideally it would use a combination of the two, because: - If rate limiting is only applied by IP address, brute force attackers could bypass this by attempting logins from multiple IP addresses (perhaps by using a botnet). - If it's only done by username, any attacker that has a list of known usernames can try a variety of commonly used passwords with those usernames and is likely to successfully break into at least a few accounts, all from the same IP address.

• However, Because rate limiting is necessary to prevent these brute force attacks, users who can't remember their passwords may be rate limited along with malicious bots. Users will likely see a "too many login attempts" message of some sort and be prompted to try again within a specified timeframe, or be advised that they are locked out of their accounts altogether.

An API, or application programming interface, is a way to request functionality from a program. APIs are invisible to most users, but they're extremely important for applications to function properly. Every time an API responds to a request, the owner of that API has to pay for compute time: the server resources required for code to run and produce a response to that API request. For this reason, any application or service that offers an API for developers will have limitations on how many API calls can be made per hour or day by each unique user. In this way, third-party developers don't overuse an API. Rate limiting can also motivate developers to pay more for leveraging the API: often they can only make so many API calls before paying more for the API service. Rate limiting for APIs helps protect against malicious bot attacks as well. An attacker can use bots to make so many repeated calls to an API that it renders the service unavailable for anyone else, or crashes the service altogether. This is a type of DoS or DDoS attack.

There is another type of rate limiting which is done via cookie based. You can have any parameter as a cookie and then do rate limiting based on that using redis. For example, if a website is using session ids to track the sessions of their users, then you can have session id based tracking.

There are many custom rate limiting solutions as well and we will be seeing one of those in this course which I developed. It's based on tracking users across the product using their ip addresses and their session ids. If any user is making too many calls to any url which is defined in the product, we can find out via tracking. We do not block them or take any action as of yet since they are valid urls but simply keep track. For users that make requests that are not in our product like /%3F%0D%0Ahrs:hrs, we throttle them based on ip address and session id. If they make more than a fixed number of calls to any request path within 1 minute, we block them for that minute. There are more advanced methods to rate limit based on increasing and decreasing limits but more on that later. If they cross the throttle, we can send emails, trigger alerts, send to any event management platform like squadcast, etc.