There are two kinds of broken login. If the site says the password is wrong when it isn't, the problem is the account, the password check, or the database. If the login "works" but you land back on the login page, the site isn't keeping you logged in: the session cookie isn't being saved or sent back. That's usually a cookie set as Secure on a site loaded over HTTP, a cookie set for www when you're on the bare domain (or the reverse), or a cached login page.
What's the problem
Users can't log in, get "invalid password" with the right password, or are bounced back to the login screen after logging in. Sometimes only on some browsers or only on mobile.
Why it happens
- Cookie not kept: a
Securecookie on an HTTP page, a cookie for a different host (wwwvs nowww), or third-party cookie restrictions when login happens in an iframe or another domain. - Caching: a CDN or cache plugin serving a cached copy of the login or account page.
- The account or password check: a locked account, a changed password, or a database problem.
- Security tools (firewall, rate limits, bot protection) blocking login attempts.
- A recent change to authentication code or settings.
- Server time wrong, making login tokens look expired.
How to fix it
- Note which kind it is: "wrong password" or "bounced back".
- For bounced back, open Developer Tools → Application → Cookies after logging in. Is the session cookie there? Check the Network tab for the
Set-Cookieheader on the login response. - Use one address: redirect everything to one host (with or without
www) and HTTPS. - Exclude login, account and checkout pages from caching.
- For "wrong password", check the server logs for the failed check, and whether the account is locked.
- Check security logs for blocked login requests.
What Preventionlabs checks
One click runs the full report on your domain. For this problem it shows whether your site loads, how fast, and where its redirects go; up to 50 pages from your sitemap, listing any that fail or are slow, plus broken links on them. With Cloudflare connected, it also shows which pages returned server errors (5xx) to visitors, and when; which requests the firewall blocked, by Cloudflare's own rule names; recent deploys and account changes, with their times. It doesn't fill in forms, log in or make payments, so test the feature yourself as well.
Run your free reportYour first report is free, no card needed. Then A$50 a month, up to 10 domains. Read-only: it never changes anything.
Sources
- MDN Web Docs: Set-Cookie headerreference
Indicates that the cookie is sent to the server only when a request is made with the https: scheme (except on localhost), and therefore, is more resistant to manipulator in the middle (MITM) attacks.
- MDN Web Docs: Set-Cookie headerreference
If omitted, the cookie is returned only to the host that sent it (i.e., it becomes a "host-only cookie").