PR #92 adds email to password reset URLs so mobile password managers can pair the reset with the existing saved credential. That behavior is acceptable, but it increases the importance of explicit URL-exposure controls on auth pages.
Current state:
Requested follow-up:
- set an explicit
Referrer-Policy for auth/reset pages (for example no-referrer, or another policy intentionally chosen and documented)
- verify the reset-password page does not load third-party resources or scripts that would make the URL exposure story worse before user interaction
- document the intended policy/constraints so future auth-page changes do not silently regress this
Relevant code:
web/src/routes/reset-password/+page.svelteweb/src/app.html- any server-side header middleware for web responses
This is non-blocking for PR #92 but should be cleaned up because the reset flow now carries account email in the URL.
PR #92 adds
emailto password reset URLs so mobile password managers can pair the reset with the existing saved credential. That behavior is acceptable, but it increases the importance of explicit URL-exposure controls on auth pages.Current state:
tokenfrom the URL and PR feat(auth): include email in password-reset URL for password-manager pairing #92 addsemailto the emitted reset linkReferrer-PolicyRequested follow-up:
Referrer-Policyfor auth/reset pages (for exampleno-referrer, or another policy intentionally chosen and documented)Relevant code:
web/src/routes/reset-password/+page.svelteweb/src/app.htmlThis is non-blocking for PR #92 but should be cleaned up because the reset flow now carries account email in the URL.