So I have seen this quite a few times now and posted the text below already, but I'd like to shed some light on this:

If you hit up your dev tools and check the network tab, you might see some repeated API calls. Those calls include a GET parameter named "token". The request looks something like this: "https://domain.tld/api/somecall/..."

You can think of this token as a temporary password, or a key that holds information about your user and other information in the backend. If one would steal a token that belongs to another user, you would have control over his account. Now many complained that this key is visible in the URL and not "encrypted". I'll try to explain why this is, well "wrong" or doesn't impose a bigger security risk than normal:

There is no such thing as an "unencrypted query", well besides really transmitting encrypted data. This fields are being protected by the transport layer (HTTPS) or not (HTTP) and while it might not be common to transmit these fields in a GET query parameter, it's standard to send those tokens as cookies, which are as exposed as query parameters. Hit up some random site. The chance that you'll see a PHP session id being transmitted as a cookie is high. Cookies are as exposed as any HTTP GET or POST Form data and can be viewed as easily. Look for a "details" or "http header" section in your dev tools.
Stolen tokens can be used to "log in" into the website, although it might be made harder by only allowing one IP per token or similar. However the use of such a that token is absolut standard and nothing special devRant does. Every site that offers you a "keep me logged in" or "remember me" option uses something like this, one way or the other. Because a token could have been stolen you sometimes need to additionally enter your current password when doings something security risky, like changing your password. In that case your password is being used as a second factor. The idea is, that an attacker could have stolen your token, but still doesn't know your password. It's not enough to grab a token, you need that second (or maybe thrid) factor. As an example - that's how githubs "sudo" mode works. You have got your token, that grants you more permissions than a non-logged in user has, but to do the critical stuff you need an additional token that's only valid for that session, because asking for your password before every action would be inconvenient when setting up a repo

I hope this helps understanding a bit more of this topic :)
Keep safe and keep asking questions if you fell that your data is in danger
Reeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee