本文说明 XChat 1.x 的受支持版本、漏洞报告方式、部署方责任和默认安全边界。安全问题不应先公开到普通 issue、群聊或公开讨论区，以免在修复发布前扩大风险。

自托管管理员应固定审核过的提交或发行版，保留 pnpm-lock.yaml，并在升级后执行 pnpm install --frozen-lockfile && pnpm test && pnpm build。Node.js 应保持在 Node 22 的最新安全补丁版本。

如果代码托管平台启用了 private vulnerability reporting，请优先使用该入口。否则请通过项目维护者在仓库主页公布的安全邮箱联系，并在主题中写明 XChat security。不要在报告中包含真实用户的消息、密码、token、Cookie、附件或未脱敏数据库。

一份可快速处理的报告应包含：

• 受影响的 XChat 版本或提交哈希、Node.js 版本、Debian 版本；
• 受影响接口或组件以及攻击者需要的账号/会话权限；
• 最小复现步骤和预期/实际结果；
• 风险说明，例如越权读取、账户接管、持久 XSS、CSRF 绕过或拒绝服务；
• 已脱敏的请求/响应、日志和概念验证；
• 你希望使用的署名方式，以及披露时间方面的限制。

维护者应在合理时间内确认收件，完成复现后给出修复与披露计划。严重漏洞在补丁可用前不会讨论实现细节。

XChat 的安全模型假设：

• Node 只监听 127.0.0.1:18282，公网流量经过受维护的 Nginx 与 HTTPS；
• /opt/xchat 对运行用户只读，/var/lib/xchat 仅 xchat 用户/组可访问；
• /etc/xchat/xchat.env 为 0640，SETUP_TOKEN 和其他未来秘密不会提交到版本控制；
• SQLite 是单机单 Node 写入模型，不把同一个数据库文件放在网络文件系统，也不启动多个 XChat 实例共享写入；
• 主机管理员可读取数据库和附件，因此不是端到端加密威胁模型中的不可信方；
• Nginx 正确转发 Host、X-Forwarded-Proto、客户端地址和 WebSocket Upgrade，且 PUBLIC_ORIGIN 与用户实际访问源完全相同；
• 浏览器、Node.js、Nginx、Debian 和文件系统均及时安装安全更新。

• 密码以 Argon2id 存储，参数为 64 MiB、3 次迭代、并行度 1、32 字节输出。
• 数据库只保存 access/refresh token 的 SHA-256 哈希；移动端收到的明文 refresh token必须存入系统安全存储。
• 浏览器凭据位于 HttpOnly Cookie；非安全方法还必须通过双提交 CSRF 校验。
• refresh token 每次使用都会旋转；已经使用过的 refresh token 再次出现时，会撤销整个设备 session。
• URL、日志、崩溃报告、分析系统和 Referer 中不得出现 access token、refresh token、setup token 或邀请明文。
• 管理员离线重置密码后，脚本会撤销该账号所有设备会话。

附件 ID 不构成授权。每次读取元数据、原文件或缩略图都会重新检查当前会话成员关系。上传以服务端 UUID 落盘，用户文件名只用于显示与 Content-Disposition。服务端限制流字节数、计算 SHA-256、检测真实类型，并拒绝 HTML、SVG、脚本和常见可执行类型。

类型检测只能降低风险，不能替代终端防病毒和内容治理。高风险部署可在 XChat 落盘目录之外增加异步恶意文件扫描，但不得让扫描器通过公网直接暴露附件目录。

使用 pnpm backup 创建数据库与附件配套快照，把快照复制到权限受控、加密并与主机隔离的位置。恢复演练应在独立机器上定期执行。怀疑凭据泄露时：

1. 从反向代理隔离服务或限制来源；
2. 保存 journal、Nginx access/error log 与只读数据快照；
3. 轮换 SETUP_TOKEN 和受影响的外部 TLS/系统凭据；
4. 暂停受影响账号或通过密码修改/重置撤销会话；
5. 修补与验证后再恢复外部访问；
6. 按适用法律和组织政策通知受影响用户。

以下通常按运维或产品问题处理：已经拥有主机 root 权限的管理员读取本机数据、管理员按产品权限删除自己管理的会话、超过事件保留期的设备被要求重新 bootstrap、部署方错误公开 DATA_DIR、未配置 HTTPS、修改源码后引入的问题，以及单机容量目标之外的性能下降。