The problem is the website administers who are encoding authentication tokens into URL state, not the naive crawlers that find them.
And sometimes it isn't practical to require a POST request or a cookie.
And the risk of a url leaking can be greatly mitigated if the url is only valid for a short period of time.
Technically you're right -- after all sending an authentication as a separate header doesn't make any difference.
GET /endpoint/?Auth=token
GET /endpoint
Auth: token
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 or https://auth:token@site.com/endpoint
Would be better than
https://site.com/endpoint/user/pass or 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)
When would this ever be necessary? URL session tokens have been a bad idea ever since they first appeared.
The only things even near to auth tokens I can reasonably see stuffed into a URL are password reset and email confirmation tokens sent to email for one time short expiration use.
Outside of that, I don't see any reason for it.
Web Applications do utilize this pattern very frequently
But as noted i previous comment these do have short expiry times (configurable) so that there is no permanent or long-term risk on the lines of the OP article
[1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...
Even if search engines knew to include it, would every insecure place a user put a link know it? Bad actors with their own indexes certainly wouldn’t care
For example, if you want a web socket server that is accessible from a browser, you need authentication, and can't rely on cookies, the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).
Then it should be the search engine at fault.
If you leave your house unlocked is one thing.
If there is a company trying everyone's doors, then posting a sign in the yard "this house is unlocked", has to account for something.
There are URL's that are out there 'as-if' public, but really should be private.
And some people argue they should be treated as private, even if it is just a plain URL and public.
Imagine if you left your house unlocked it would be broken into seconds later. Even worse, the people that broke into it live in a different country with no extradition law and you'd never figure out who they are anyway.
In this case your insurance company would tell you lock your damned doors and the police may even charge you under public nuisance laws.
Just like charging people for a crime for accessing private material, simply by browsing a public URL.
Maybe Better take:
It is like someone being charged for breaking and entering, simply by looking at a house from the street, when the door was left open. Your guilty by simply looking, and seeing inside. But you were just walking by, you saw inside before realizing it was a crime, now your guilty.
If you are going to charge people for accessing private sites, potentially by accident, by simply being provided a public URL from a search engine. Then shouldn't the search engine have some culpability?
Or. Better. Change the law so the onus is on the site to protect itself.
If that sounds ridiculous, it’s because it is. And yet, add in a computer and the Internet, and that’s basically what a newly unsealed federal indictment accuses Florida journalist Tim Burke of doing when he found and disseminated outtakes of Tucker Carlson’s Fox News interview with Ye, the artist formerly known as Kanye West, going on the first of many antisemitic diatribes.""
https://arstechnica.com/tech-policy/2024/03/charges-against-...
"According to Burke, the video of Carlson’s interview with Ye was streamed via a publicly available, unencrypted URL that anyone could access by typing the address into your browser."