Skip to content

Security: zachtidwell/shelfmark-eink

SECURITY.md

Security Policy

Supported versions

The main branch and the latest image built from it. There are no maintained release branches — fixes land on main and a new image is published.

Reporting a vulnerability

Please report privately via GitHub's Report a vulnerability button on the Security tab, rather than opening a public issue.

Include what you were able to reach, and the deployment shape you tested (direct LAN, reverse proxy, HTTPS or plain HTTP). This is a hobby project — a fix may take days rather than hours.

Known design tradeoffs — please don't report these

Three properties are deliberate, documented in the README, and not bugs:

The ?key= token is a bearer credential carried in a URL. It is the user's password, encrypted with a key derived from SECRET_KEY, and the server decrypts it to authenticate to Shelfmark. Anyone holding that URL has the account's access. This exists because the target browsers — the WebKit builds on Kobo and Kindle readers — discard cookies when the browser closes, so a bookmarkable URL is the only mechanism that survives. It is a real tradeoff accepted for a real constraint.

That token has no expiry and no revocation. Rotating SECRET_KEY invalidates every outstanding token at once (and logs out every device); there is no per-token revocation.

COOKIE_SECURE defaults to false. A Secure cookie is never sent over plain HTTP, and the intended deployment is plain-HTTP LAN access. Serving over HTTPS without setting it true is a misconfiguration, not a vulnerability.

The intended deployment is a home LAN or a VPN. This application is not built to face the public internet, and reports amounting to "it is insecure when exposed to the internet" are already answered by the README.

In scope

Anything that breaks the model above, including:

  • Reaching the credentials in plaintext — from the cookie, the ?key= token, a log, or an error page.
  • Acting as another user, or reaching the app without any valid token.
  • Making the cover proxy fetch from a private or attached-subnet address (_cover_url_allowed in app.py is the control; bypasses are bugs).
  • Redirecting a user off-site through next, or any injection into a rendered template.
  • Anything that escapes the container or reaches the Docker host.

There aren't any published security advisories