Secret passed as a param risks MITM attack

[posthello-code]

Putting sensitive information in the url (such as https://listed.to/authors/{id}/settings/?secret={secret}) is not a recommended practice since this information is plainly visible in server logs and could be intercepted by a third party.

This risk would be mitigated if the secret token was a one time use, or could be revoked by the associated standard notes account in case of compromise, but that doesn't appear to be possible.

[moughxyz]

Indeed, something we hope to improve upon. Listed runs on pretty legacy Rails and has not been brought up to date with the rest of our infrastructure, but we're slowly inching our way there. Likely we cannot get around passing it in the URL for GET requests like opening up the user Settings page but we can explore short-lived tokens.

[Lissy93]

Any update on this? I feel like it's a pretty major security issue, since with that token, all private posts can be found, posts can be edited/ deleted and settings modified. Possibly an alternative could be to use Standard Notes auth?

What's the plan for the updated version of Listed (tech stack, timelines, etc)? I would definitely be happy to help out with any dev tasks if needed 💕 I find that it's a really useful tool, and I would love for it to be more actively maintained.

[moughxyz]

No major upgrades or architectural changes planned for Listed right now, as much as we love the service. We don't have the capacity to undertake any big architectural refactors for it right now, as our present focus is our main app stack.

Although ephemeral tokens would be an improvement, the security concern here is in my opinion theoretical and not too practical. The only parties that could see a query param in an https request is you and us. On our end we're careful not to log this parameter as it passes through our infrastructure stack.