Report security problems privately, not as a public issue. Open the Security tab of the repository and choose Report a vulnerability. That opens a private advisory that only the maintainers can read.

Include everything that we need to act: the affected version or commit, the configuration (open mode or auth mode, because they have different trust models), and the smallest reproduction that you can make. We acknowledge the report, and we keep you informed while we work on a fix.

Fixes ship in a normal tagged release. If a report needs one, we also publish a GitHub Security Advisory, and we credit you unless you prefer to stay anonymous.

Security fixes land on main and go out in the next tagged release. Older tags are not patched. click update keeps the CLI current, and a deployment must track a recent clickd image.

The security-relevant design is documented. Read it before you report, so that we can tell a real finding from documented behavior:

• AGENTS.md — the load-bearing invariants. The most important one is that nginx is the trust boundary. nginx derives X-Click-Site from the subdomain and injects X-Auth-Request-Email from the auth proxy. It always overwrites both, so handlers trust nginx and never the caller. clickd must never accept a site name or an identity from the caller. A way to make it do so — through a request body, a query string, or a client-supplied header — is a genuine vulnerability.
• DESIGN.md — the authentication and ownership model, and per-site isolation. Every query filters on the site. nginx routes each subdomain to its own S3 prefix. The STS session policy narrows a deploy to sites/<site>/*, and the libSQL backend gives each site its own database. A path that crosses any of those boundaries is in scope.
• DESIGN.md § Known limitations — behavior that is deliberate, not a defect. Two points matter most. Open mode has no identity layer at all, so anyone with bucket credentials can overwrite any site. And in both modes the document database is isolated per site, not per user. Any signed-in user can therefore read and write the documents of a site. Neither is a vulnerability. Both are the documented model.

The local development stack is not a target. auth/dex.yml ships two static users with the password password and the example bcrypt hash of dex, and docker-compose.yml uses the default MinIO credentials. All of it is meant for localhost. Never let any of it reach a real deployment.