> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. Technically you're r

> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. Technically you're right -- after all sending an authentication as a separate header doesn't make any difference. GET /endpoint/?Auth=token or GET /endpoint Auth: token Sends the same data over the wire. However software treats URLs differently to headers. They sit in browser histories, server logs, get parsed by MITM firewalls, mined by browser extensions, etc using https://user:pass@site.com/endpoint https://user:pass@site.com/endpoint or https://auth:token@site.com/endpoint https://auth:token@site.com/endpoint Would be better than https://site.com/endpoint/user/pass https://site.com/endpoint/user/pass or https://site.com/endpoint/?auth=token https://site.com/endpoint/?auth=token As the former is less likely to be stored, either on the client or on the server. I don't do front end (or backend authentication -- I just rely on x509 client certs or oidc and the web server passes the validated username)