In one paragraph
A missing /.well-known/change-password route makes it harder for supported password managers to take users directly to password settings. Add a temporary redirect to the real change-password page, preserving a safe login-and-return flow when necessary. This is a usability improvement, not a password reset endpoint or permission to bypass authentication. Verify the destination rather than merely clearing a status-code check.
Why it matters
Password managers can warn about compromised or weak saved credentials, but that warning is less useful if the user cannot find where to replace them. A well-known route provides a consistent entry point while allowing your account-settings URL to change behind it.
The destination still needs your normal authentication and sensitive-action protections. Opening the shortcut must not itself change a password, generate a privileged session, or expose reset tokens. For accounts managed by a separate identity service, direct users to the appropriate legitimate settings flow.
Support varies by product and browser. Implementing the shortcut does not guarantee every manager will use it or automatically complete a change. It removes one navigation obstacle for clients that support the convention.
How WebAuditOS evaluates this finding
The supplied probe runs when a crawled link's text or address matches login, signin, or sign-in. That heuristic can miss spaced wording and can trigger on an external portal. No matching evidence or no response is not graded.
A redirect ending below status 400 passes. A direct 200 can pass when an unrelated nonexistent path does not also return 200; otherwise the response can remain ungraded as a possible soft 404. Other errors warn informationally. The probe does not establish that a passing destination actually contains password settings: a redirect to a homepage can pass while helping nobody.
How to fix it
- Identify the real settings page for a signed-in user. Distinguish changing a known password from forgotten-password recovery, initial registration, and account deletion. Choose the destination relevant to the service's account model.
- Add an exact HTTPS route for /.well-known/change-password. Use a temporary redirect such as 302, 303, or 307 so the destination can evolve. For example, in nginx:
location = /.well-known/change-password {
return 302 /account/password;
}Replace the destination with your actual settings route. The example assumes a suitable same-origin HTTPS deployment, not an application with a different identity host.
- If settings require login, retain a safe internal return destination through the login process. Validate return URLs to avoid an open redirect, and do not place authentication secrets into the shortcut's query string.
- For a separate account service, redirect to its approved HTTPS settings page. Test account and organisation context so the user does not land on an unrelated identity profile.
- Ensure routing and middleware recognise the well-known path before a single-page-app catch-all. Unknown URLs should return meaningful not-found responses rather than a universal 200 shell that makes feature detection unreliable.
- Check that bot challenges and access filters do not unnecessarily obstruct the public navigation entry. The private destination can still require authentication; do not expose settings to satisfy an external scanner.
- Test signed-in, signed-out, cancellation, and unsupported-account paths. Inspect the redirect chain and confirm that a user who signs in arrives at the intended page. Test with a supported password manager where practical.
- Verify current-password and new-password autocomplete hints on the destination form, then rescan. A successful redirect and a usable secure change form are complementary requirements.
What the fix can break
A wrongly chosen destination can send users into recovery instead of account settings or create a login loop. Include real account types and federated sign-in in tests.
Broad redirect rules can accidentally match other well-known endpoints. Use an exact route and preserve unrelated certificate, identity, and disclosure paths.
For a service with no local passwords, document the appropriate identity-provider flow or explain the limitation. Do not invent a form or weaken authentication solely because a heuristic detected the word login.
Questions
Should this route change the password automatically?
No. It is a navigation shortcut. The actual settings action still requires the normal authenticated, authorised flow.
Why does a homepage redirect pass the scanner?
The documented probe checks a successful destination, not the form's purpose. Manually confirm that the endpoint is useful.
Should I use a permanent redirect?
The implementation guidance recommends temporary redirect codes such as 302, 303, or 307 so the settings URL can change more easily.
What should I review next?
Review password autocomplete and HTTPS password forms.