Back
How to protect your login page from bots
See how bots target login flows and how to stop credential attacks without adding friction for real users
How to protect login pages from bots – without blocking real users
A login page is one of the most valuable automation targets on a website. Bots use it to test stolen passwords, guess weak credentials, spray one password across many accounts, enumerate users and abuse password-reset flows. The requests can look ordinary one by one. The danger appears in the pattern.
The practical answer is layered login protection: harden the accounts, monitor authentication traffic, throttle abuse around the account and workflow, add step-up checks only when risk rises, and filter malicious automation before it reaches the application. OWASP recommends the same defence-in-depth approach because no single control completely covers brute force, credential stuffing and password spraying. Source: OWASP Authentication Cheat Sheet.
TL;DR
Protect the whole authentication journey, not just the password field. Start with MFA for privileged accounts, compromised-password blocking, generic login errors, account-aware throttling and monitoring. Use CAPTCHA or extra authentication as a selective step-up control, not permanent friction for every customer. Then detect and stop automated login traffic at the perimeter before it can keep testing your application.
First: know which login-bot problem you are solving
“Login bot” is a useful business phrase, but several different automated attacks can sit behind it. They need overlapping controls, not identical responses.
OWASP distinguishes brute force, credential stuffing and password spraying by the way credentials are tested. Credential stuffing specifically replays username/password pairs stolen elsewhere rather than guessing new values. Source: OWASP OAT-008.
| Attack | What the bot does | Why it matters |
|---|---|---|
| 01Brute force | Many password guesses against one account. | Weak passwords eventually fall; aggressive lockouts can also be abused against the customer. |
| 02Credential stuffing | Known username/password pairs from another breach are replayed at scale. | A small success rate is enough to produce account takeover. |
| 03Password spraying | One common password is tried against many accounts. | Per-account volumes stay low, so simple thresholds can miss the campaign. |
| 04Account enumeration | The attacker learns which usernames or email addresses exist. | The verified account list makes later password attacks more efficient. |
| 05Recovery abuse | Bots hammer password-reset or recovery endpoints. | Users get flooded, accounts are probed, and recovery becomes another attack surface. |
Do not solve the wrong problem
A login rule that only says “block an IP after ten failures” can slow a basic brute-force script and still miss a distributed credential-stuffing campaign. The same control can also lock out a real customer behind a shared network. Protection needs account, workflow and traffic context.
Step 1: watch every authentication endpoint, not only /login
Start by mapping the full authentication surface. For many sites that means login, password reset, password recovery, one-time-code verification, account activation, admin login and any API endpoint used by a mobile app or headless frontend.
You want enough evidence to see rate, spread and outcome. A single failed login is normal. Ten thousand failed logins spread across thousands of accounts is not. A reset endpoint that suddenly receives repeated requests for the same small group of addresses is also worth investigating.
- Log authentication outcomes: successful and failed attempts, lockouts, reset requests and step-up challenges.
- Compare attempts per account and per network source: distributed attacks deliberately avoid obvious per-IP spikes.
- Watch endpoint concentration: bots often hammer one path while normal customers move through several workflows.
- Track success after repeated failures: a later successful login can matter more than the failure count itself.
- Protect recovery too: OWASP recommends controls against excessive automated reset submissions, including rate limiting and other step-up measures.
10-minute check
Look at the last 24 hours of failed logins. Sort once by account and once by source. Then compare the same period with password-reset activity. You are looking for repeated structure: many passwords against one account, one password pattern across many accounts, or low-volume attempts distributed across many sources.
Step 2: make stolen and weak passwords less useful
Bot mitigation should not carry the whole authentication problem. If the attacker already has a valid password, stronger account security reduces what successful automation can achieve.
For administrative and privileged accounts, MFA should be the baseline. OWASP calls MFA the strongest defence against most password-related attacks, while current NIST guidance requires stronger authentication at higher assurance levels and explicitly supports phishing-resistant options such as WebAuthn/FIDO2. Source: NIST SP 800-63B-4.
- Require MFA for every admin and privileged role. Do this before tuning bot rules.
- Offer strong MFA or passkeys to customers. High-value accounts deserve an easy upgrade path.
- Reject commonly used and compromised passwords at creation and reset. NIST requires comparison against a blocklist of known common, expected or compromised values.
- Allow password managers, autofill and paste. Do not make unique passwords harder to use.
- Do not force arbitrary periodic password changes. Rotate when there is evidence of compromise or a user-driven reason, not because the calendar says so.
Important distinction
MFA protects accounts even when a password has been stolen. It does not remove the bot traffic hitting your login endpoint, consuming resources, testing usernames or attacking customers who have not enabled MFA. Account security and automation control solve different layers of the problem.
Step 3: stop your login flow from teaching bots which accounts exist
Attackers become more efficient when your application tells them which usernames are valid. Different messages such as “account not found”, “wrong password” and “account disabled” can turn the login form into an account-discovery tool.
OWASP recommends generic authentication responses across login, password reset and recovery flows. The visible message is only part of the job: different HTTP responses or meaningfully different processing times can also leak whether an account exists. Source: OWASP.
- Login: use one failure response for invalid username or password.
- Password reset: respond as if the request was accepted whether or not the email exists.
- Registration: avoid unnecessary account-existence disclosure where the business flow allows it.
- HTTP behaviour: do not reveal validity through different status codes or response bodies.
- Timing: avoid obvious fast-fail paths for unknown usernames if valid usernames trigger much more processing.
Step 4: throttle the account and the workflow – not only the IP
Rate limiting is useful, but a login limit tied only to source IP is easy to route around. Residential proxies and distributed infrastructure let a campaign stay under a simple per-IP threshold while the same accounts keep receiving attempts.
OWASP recommends associating failed-attempt controls with the account itself and warns that lockout design must balance security with denial-of-service risk. It also recommends considering short bursts and low-but-consistent distributed traffic, not one predictable volume threshold.
- Use account-aware failed-attempt limits. The attacker should not gain unlimited guesses simply by changing IP.
- Add endpoint-level rate limits. Login, reset and OTP verification deserve their own budgets.
- Use progressive responses. Slow, challenge or step up suspicious traffic before jumping immediately to a long hard block.
- Keep lockouts recoverable. Otherwise an attacker can deliberately lock customers out.
- Measure false positives. A security control that blocks legitimate customers during a promotion is a business incident too.
Why IP-only blocking fails
Distributed credential-stuffing tools are designed to rotate sources. OWASP explicitly warns that proxy networks can keep per-IP request volume low enough to defeat IP blocklists and simple rate limits. IP is one signal, not an identity.
Step 5: use CAPTCHA and step-up authentication selectively
CAPTCHA can still raise the cost of unsophisticated automation, but it should not be your definition of login security. OWASP treats CAPTCHA as a defence-in-depth control because automated solving and outsourced solving can bypass it.
For SMB sites, the practical pattern is progressive friction: let normal login traffic stay normal, then add another check when the request looks risky. That check might be CAPTCHA, MFA, email verification or another business-appropriate step.
- Do not challenge every customer by default. Permanent friction punishes the people you want to keep.
- Trigger step-up after suspicious behaviour. Repeated failures, distributed attempts or unusual recovery activity are stronger reasons.
- Keep MFA separate from CAPTCHA. CAPTCHA tries to slow automation; MFA proves control of another authenticator.
- Review challenge solve rates and abandonment. Security controls need UX metrics too.
Step 6: stop automated login traffic before it reaches the application
The controls above harden authentication even if some malicious traffic gets through. The next layer is to reduce that traffic before it can repeatedly exercise the login workflow.
Modern login automation often imitates a normal browser and spreads requests across many networks. That makes single-rule detection brittle. Effective bot protection needs to correlate behaviour, browser, network, request sequence and endpoint rather than trusting one header or one IP address.
This is especially important for credential stuffing. OWASP classifies credential stuffing as an automated threat built around mass login attempts using stolen credential pairs. A perimeter layer can reduce that automation before the application has to process every attempt.
The goal
Do not try to prove that every failed login was malicious after the fact. Reduce the automated traffic reaching login, password-reset and related authentication endpoints, while letting real customers and legitimate crawlers continue normally.
A practical 60-minute login-bot hardening plan
01
Map the endpoints. List login, admin login, reset, recovery, OTP and authentication API routes.
02
Turn on useful authentication logging. Confirm you can see failures, successes, lockouts and reset requests.
03
Enable MFA for admins. This is the highest-ROI account control on the list.
04
Check password policy. Block compromised/common passwords and allow password-manager-friendly entry.
05
Review error messages. Remove easy account-enumeration clues from login and recovery.
06
Set account-aware throttling. Do not rely on one per-IP threshold.
07
Move friction to risky traffic. Use CAPTCHA or step-up verification selectively.
08
Measure the traffic layer. Establish how much automated traffic reaches authentication endpoints before adding more rules.
Do this first
If you only have time for three actions today: require MFA for admins, review the last day of authentication logs, and verify that password-reset and login endpoints have abuse controls. Then measure the remaining automated traffic before tightening customer-facing friction.
Five common login-protection mistakes
| Mistake | Why people do it | Where it breaks |
|---|---|---|
| 01Block by IP only | Fast to deploy. | Distributed attacks rotate sources and stay below each IP threshold. |
| 02CAPTCHA every login | Easy to understand. | Adds friction to every customer while sophisticated automation can still solve or outsource challenges. |
| 03Hard lockouts too early | Stops repeated guesses. | Attackers can intentionally lock out customers. |
| 04MFA only | Strong account defence. | Does not stop enumeration, reset abuse, resource consumption or attacks on users without MFA. |
| 05Bot filtering only | Reduces automation. | Does not replace secure passwords, MFA, safe recovery or application-side authentication controls. |
The strongest setup is deliberately boring: secure authentication + abuse-aware application controls + automation filtering. Each layer assumes another layer can fail.
How ADPAL handles the automation layer
ADPAL sits in front of the website and evaluates requests before they reach the protected application. For login protection, Advanced detection correlates behaviour, browser, network, request sequence and endpoint to identify automated abuse without relying on a single static rule.
That lets your application-side controls focus on authentication: MFA, password policy, recovery and account risk. ADPAL focuses on reducing the malicious automation repeatedly exercising those workflows.
Cookieless, no cross-site tracking profiles, EU (Frankfurt) data residency.
Deployment
Point your DNS at the managed reverse proxy – live in hours, then a short monitoring period before enforcing. CMS-integrated deployment is available through hosting partners.
Frequently asked questions
How do I stop bots from trying to log in?
Use several layers: MFA and strong password policy for the accounts, account-aware throttling around authentication attempts, safe recovery and generic errors, selective step-up challenges, and bot filtering before automated requests reach the login workflow. One IP blocklist or one CAPTCHA is not enough for modern distributed attacks.
Is rate limiting enough to protect a login page?
No. It is useful against crude high-volume attempts, but distributed credential stuffing can spread requests across many sources. Rate limits should consider the account and endpoint, and they should sit alongside MFA, logging, recovery protection and automation detection.
Should I put CAPTCHA on every login?
Usually not. OWASP treats CAPTCHA as defence in depth rather than complete prevention. A better customer experience is to challenge suspicious traffic selectively after risk rises, while normal users continue through the normal login flow.
Does MFA stop login bots?
MFA is one of the strongest controls against password-based account compromise, because a stolen password alone is no longer enough. But MFA does not stop the bot from hitting your login or reset endpoints, enumerating accounts, consuming resources or attacking users who have not enabled it.
What is the difference between brute force and credential stuffing?
Brute force guesses many passwords against an account. Credential stuffing replays username/password pairs already stolen from another service. Password spraying is different again: one weak password is tested across many accounts. The distinction matters because their request patterns differ.
How do I protect login pages without locking out real customers?
Avoid one blunt rule. Use account-aware throttling, progressive delays or temporary mitigation, selective challenges and continuous measurement of false positives. Hard lockouts need a safe recovery path so attackers cannot weaponise them against customers.
Should password-reset endpoints get the same protection as login?
Yes. Recovery is part of the authentication surface. Bots can flood reset requests, probe which accounts exist and abuse verification steps. Monitor and rate-limit recovery flows, keep responses generic where appropriate, and include those endpoints in bot detection.
Protect the login flow before the account is at risk
A secure login page does not depend on one heroic control. Make stolen passwords less valuable, stop the application leaking account information, throttle abuse safely, add stronger authentication where it matters and keep automated traffic from repeatedly exercising the workflow.
If you already see login spikes, password-reset floods or customer complaints about unfamiliar access, start with evidence: measure the automated traffic reaching the authentication endpoints, then tighten the layer that is actually failing.
Next step
See how much automated traffic is reaching your site and which endpoints it targets. Then decide what should be allowed, challenged, limited or blocked.