Goodreads Developers discussion

Librarian's API security

Comments Showing 1-2 of 2 (2 new)    post a comment »
dateDown arrow    newest »

message 1: by Botmtl (new)

Botmtl | 2 comments The api librarians use to edit book is not part of the official api so this might not be the right venue for this question.

I recently noticed that /book (put request) does not require the "72 hours" cookie that protects users mail inboxes for example. All it requires is the user's id cookie, the one that can be made permanent (the 30 year cookie). Also I think the permanent cookie is constant? across sessions, which is problematic as well.

If I were to open a goodreads session in a publicly available browser, and forget to log off, I would be at risk, as long as the browser cache is not cleared of a prankster making library edits under my name (deleting books, editing author info, etc.). Worse, the only thing I could do on my side would be to delete my account (if my presumption about that cookie being constant across session is right).

This may be by design, but looks to me like an oversight. I know that personally, I'm way more scared of that hypothetical prankster editing books than he/she accessing my inbox. I saw an authenticity_field in the forms, could'nt that value be based on the 72hour cookie? Or if it's all htaccess based, couldnt the same security measures be applied to /book(put) than /inbox has?

Note: I don't really have the know-how and there will be obvious errors in this post. I know the words, but I don't have any deep insight into what I'm talking about. If a goodreads employee is tasked with looking into this, the only thing I know for sure is that if I open my browser in 6 months I'll still be able to edit books, without a fresh login token.

message 2: by Botmtl (last edited Apr 18, 2019 07:00PM) (new)

Botmtl | 2 comments If adding security checks to the request would break in-house tools, denying access to /book/edit/goodreadsbookid without a session cookie would at least hide the issue to the casual observer (even though the librarian api would still be vulnerable to direct calls).

back to top