Here's an example of an HN password reset link:
hxxps://news.ycombinator.com/x?fnid=<long-random-value>&fnop=passwd-reset
`fnid` identifies a closure. Presumably there's a hashmap of `fnid` values to closures in memory.
It used to be that this was how any action on the site was represented. I poked around for a minute though, and it's evidently not the case for upvotes any more:
hxxps://news.ycombinator.com/vote?id=<integer>&how=up&auth=<long-random-value>&goto=<return-url>
I'm interested in whether the password reset link is a potential issue still.
Using GET to change state, like they're discussing in that thread, is really more of a style issue than a security issue. You need a CSRF token, whatever verb you use.
And that was a few years before my recollection of upvotes using an `fnid`. (I could also be misremembering.)
In the case of password resets, I don't think there's a functional difference between using a map of closures with random tokens and comparing random tokens stored in a database, as is the more conventional approach. If you can guess the random token, or if you can extract them via a side channel, then you can reset passwords. And if you can't, you can't.
Which isn't to say it's not worth having a look :)