Readeck exposure needs token scope and session review

Readeck is a self-hosted reading and bookmark service. Its API supports per-user access tokens and an OAuth flow with scopes. That is a useful security model for a service that stores reading history, saved pages, and personal annotations. It also means an exposed Readeck instance has more than one way to authenticate a request.

On 9 November 2026 at 08:50 Asia/Shanghai, a ZoomEye query using sub_type=all, page 1, and page size 1 returned 527 assets for title="Readeck" && http.body="Readeck". The title query returned 542, the body query returned 610, and the application fingerprint returned zero. The title-and-body intersection is the conservative inventory for this product name.

The query is reproducible through the selected ZoomEye search.

API tokens are a second session

Readeck's API documentation describes a profile page where a user can create an API token and then send it with the Bearer authorization scheme. The source package documentation describes the token authentication provider and CSRF-exempt behavior for token-auth requests.

The token is a credential, not a browser convenience. It can be copied into a script, a mobile client, or a CI job. Inventory the tokens by owner, application, creation date, and last use. Revoke a token when the integration is removed or the user no longer needs it.

Do not log the token in an HTTP request line. Do not place it in a URL that is sent to a third party. The API client should store it in the platform's protected credential store and send it in the authorization header.

OAuth scopes reduce but do not remove authorization work

Readeck's OpenAPI documentation lists bookmarks:read, bookmarks:write, and profile:read as OAuth scopes. A route can require a scope, and a route without one is not available to an OAuth token. That is a better boundary than a single all-purpose token, but the resource server still has to enforce the scope on every route.

Test a read-only token against create, update, delete, and export endpoints. Test whether the token can read another user's bookmark by changing an object ID. A scope that says bookmarks:read should not imply access to every user's bookmarks.

Review the client registration and redirect flow if the instance supports OAuth clients. A dynamically registered client still needs a redirect URI that the authorization server can trust. The token endpoint and the resource endpoint should agree on the token audience and user identity.

Session behavior and reverse-proxy headers

The browser session is a separate authentication path. Review cookie attributes, session lifetime, logout behavior, and CSRF protection at the public edge. A token-auth route may be exempt from CSRF because it uses a bearer credential. A browser route should not inherit the same exemption merely because the application supports tokens.

If Readeck runs behind a reverse proxy, verify which client-address headers the application trusts and which proxy overwrites them. The API and UI may use the address for rate limiting or audit records. A header supplied by an untrusted client can make those records ambiguous.

Test the public URL and the internal container URL separately. An operator may protect the browser UI with an access proxy while leaving the API route reachable through a second hostname.

Practical checks for an owned instance

Create a normal user and one API token with the narrowest available scope. Try the token against the user's bookmarks, another user's bookmark, the profile endpoint, and a write endpoint. Revoke the token and repeat the same request. Then log the user out of the browser and confirm that the API token's behavior is independent.

Review the storage and backup path. Readeck keeps saved content that may include private articles, notes, and article metadata. Backups need encryption and access control even when the web application is patched and the public login is strong.

The 527 matches do not prove that every Readeck deployment exposes private data. They identify pages with the title and body markers used by the application. For each owned host, compare the public routes, token scopes, user boundaries, and proxy controls. The security value is in making those access paths agree.

References

• Readeck source documentation, Authentication and OAuth scopes
• Readeck Go package documentation, Authentication providers
• Readeck Go package documentation, Server authentication providers