Memos 安全策略全解：版本支持、漏洞上报流程与自托管部署安全实践

本文基于仓库根目录的 SECURITY.md 展开，系统讲解 Memos 当前 0.x 阶段的安全支持范围、私密的漏洞上报流程与披露策略，并结合 server/cors.go、server/auth/token.go 等源码，说明“自托管实例的安全性一半取决于部署者”这一论断背后的具体技术依据。读完后你将掌握如何正确向官方提交漏洞报告，以及如何按官方建议完成 TLS、反向代理、认证与访问控制的部署配置。

支持版本：0.x 阶段只维护最新发行版

SECURITY.md 的 Supported Versions 一节给出了明确的支持边界：

• Memos 目前处于 0.x 阶段，安全修复只提供给最新发行版（latest release）；
• 旧版本不获得安全更新，修复不会向下回溯（backport）；
• 官方建议：如果将 Memos 用于生产环境，请将实例保持在最新发行版上。

这一策略与仓库的发布机制完全吻合。从 release-please-config.json 可以看到，项目采用 release-please 自动化发版，versioning 为 prerelease、预发布类型为 rc.1，变更日志统一写入 CHANGELOG.md，并划分为 Features、Bug Fixes、Performance Improvements、Dependencies、Reverts 五个小节。也就是说，安全修复会自然进入常规发布流的 “Bug Fixes” / “Dependencies” 小节中——这也正是 SECURITY.md 中 “fixes may be shipped directly in normal releases or noted briefly in release notes” 这句话的现实对应。

从工程视角看，0.x 阶段“只修最新版、不回溯”是合理的成本控制策略：数据库迁移脚本（见 store/migration 下 sqlite/mysql/postgres 三套按版本组织的 SQL 文件）跨大版本并不总可平滑回放，回溯旧版本的修复可能引入兼容性风险。因此对自托管用户的直接要求就是：把升级最新发行版纳入例行运维，而不是等出问题时再追平。

漏洞上报：走私密邮件通道，并附完整复现材料

SECURITY.md 规定了一条清晰的上报规则：安全类问题必须通过邮件 [e-mail] 私密报告，禁止以公开的 GitHub issue、discussion 或 pull request 形式提交疑似漏洞。

官方给出的报告内容清单（原样继承自文档）如下，提交时建议逐条对照：

• 对问题的清晰描述（A clear description of the issue）；
• 复现步骤（Steps to reproduce）；
• 受影响的版本或 commit（Affected version or commit）；
• 对复现有影响的部署细节（Deployment details that matter to reproduction）；
• 你对影响面的评估（Your assessment of impact）。

其中“部署细节”这一条尤其重要，因为 Memos 的很多行为会随部署方式变化。例如反向代理是否透传了正确的 Host/Origin、InstanceURL 是否配置，都会直接影响 CORS 与 Cookie 行为（后文详述）。报告时提供这些信息能显著提高排查效率。

官方同时承诺：报告会在时间允许时审阅，确认有效的漏洞会在常规发行版中修复。

披露与 CVE 策略：不单独发布安全公告

SECURITY.md 的 Disclosure and CVEs 一节说明：作为仍处于 0.x 阶段的自托管软件，Memos 不运行正式的漏洞披露项目，不为每个问题单独发布安全公告（security advisory），也不申请 CVE 编号；安全修复可能直接随常规版本发布，或仅在 release notes 与 changelog 中简要提及。

由此可推断出对使用者的两点含义：其一，跟踪 CHANGELOG.md 是感知安全变更的主要渠道；其二，如果你的合规流程依赖 CVE 编号做漏洞台账，需要对 Memos 单独维护“版本—发布日期—changelog 条目”的映射，而不能依赖外部 CVE 数据库自动覆盖。

部署安全基线：官方五条建议与源码级佐证

SECURITY.md 指出：Memos 实例的安全状况很大程度取决于部署与运维方式，并给出五条核心建议：

1. 保持 Memos 更新（Keep Memos updated）；
2. 暴露到互联网时，放在配置正确的反向代理之后（Put it behind a properly configured reverse proxy）；
3. 任何非公开用途的部署都必须启用认证（Require authentication）；
4. 生产环境使用 TLS（Use TLS in production）；
5. 将访问权限限制在可信用户和管理员范围内（Limit access to trusted users and administrators）。

以下逐条结合仓库源码说明这些建议对应的具体机制，帮助部署者理解“配置正确”到底指什么。

更新与绑定地址：官方默认不直接暴露公网

README.md 中的 Quick Start 给出的 Docker 命令把端口绑定在回环地址上：

docker run -d \
  --name memos \
  --restart unless-stopped \
  -p 127.0.0.1:5230:5230 \
  -v ~/.memos:/var/opt/memos \
  neosmemo/memos:stable

-p 127.0.0.1:5230:5230 意味着官方默认部署并不监听外部网卡，访问需经过本机或同主机的代理层——这正是建议第 2 条“放在反向代理之后”的默认形态。若你改为 -p 5230:5230 或绑定 0.0.0.0，就等于把无 TLS 的 HTTP 服务直接暴露出去，这属于文档明确指出的“部署问题”范畴（见下文）。

认证：访问令牌、刷新令牌与 PAT 的分工

“Require authentication” 在源码中对应 server/auth 包定义的三套凭证体系（见 server/auth/token.go 的包注释与常量定义）：

凭证类型	有效期	用途	校验方式
JWT Access Token	15 分钟（AccessTokenDuration）	API 访问	仅验签，无状态
JWT Refresh Token	30 天（RefreshTokenDuration），Cookie 名 memos_refresh	换取新的 access token	需对照数据库做吊销检查
Personal Access Token（PAT，前缀 memos_pat_）	长期	程序化访问	存储为其 SHA-256 哈希

关键实现在 server/auth/token.go 中：token 使用 HS256 签名并携带 kid: v1 头，verifyJWTKeyFunc 会拒绝签名算法或 key ID 不符的 token，ParseAccessTokenV2 / ParseRefreshToken 还分别校验 issuer（memos）、audience（user.access-token / user.refresh-token）与 type 声明，防止两类 token 被混用。密码方面，用户密码以 bcrypt（bcrypt.DefaultCost）哈希落库，见 server/router/api/v1/auth_service.go 中的 bcrypt.CompareHashAndPassword 与 server/router/api/v1/user_service.go 中的 bcrypt.GenerateFromPassword。

对部署者的含义：短时效 access token + 可吊销的 refresh token 组合已经提供了“会话可以失效”的能力，但前提是不要绕过认证直接开放接口，并且要理解 refresh token 依赖 Cookie（SameSite=Lax），这与下一节的 CORS 设计强相关。

反向代理与 CORS：为什么 InstanceURL 是安全配置

Memos 的 CORS 中间件（server/cors.go）采取了一个值得部署者理解的分层策略：

• API 对任意 Origin 开放，目的是让携带 Authorization 头的 token 客户端（Access Token V2 / PAT）可以从任何地方调用；
• 但携带凭证（即 SameSite=Lax 的 refresh-token Cookie）的访问只对可信 Origin 授予：与请求 Host 相同，或与配置的 InstanceURL 的 scheme + host 完全一致（isAllowedCORSOrigin，server/cors.go）；
• 全局 AllowCredentials 故意保持 false，由代码针对单个可信 Origin 动态追加 Access-Control-Allow-Credentials: true。源码注释明确警告：若对所有反射 Origin 输出该头，恶意同站子域名就能读取 Cookie 认证的 /auth/refresh 响应并窃取 access token；
• 代码同时拒绝反射 null Origin（沙箱 iframe、file:// 页面）。

由此可以推断出两条部署实践：其一，反向代理必须正确传递/终结 Host 与 Origin 语义，代理层若改写 Host 或混用多个域名，会导致“可信 Origin”判定失真；其二，如果存在合法的外部访问入口，应通过 --instance-url 将其配置到 InstanceURL，该值会经过 internal/profile/profile.go 的 normalizeInstanceURL 严格校验——只允许 http/https 且必须含 host，不允许携带用户名密码、query 或 fragment，配置错误会在启动阶段直接报错，而不是静默降级。

TLS 与访问控制：生产环境收尾

“生产环境使用 TLS” 这条建议与上面的机制相扣：refresh token 走 Cookie 传输，TLS 是防止中间人截获长期凭证的最后一道防线；InstanceURL 的校验允许 http 也允许 https，但后者才是互联网暴露场景下的正确选择。

“把访问限制在可信用户和范围内”则对应产品内建的权限模型：实例提供用户角色（如 ADMIN 与普通用户）与 Space 级别的成员管理，普通公开分享走 memo 的 visibility 机制。部署者应定期在后台审阅用户列表与 Space 成员，把账号收敛到最小集合。

何时算“部署问题”而非产品漏洞

SECURITY.md 最后一条规则同样值得逐字掌握：完全依赖故意不安全的选择、不受支持的本地补丁或管理员操作而触发的报告，可能被认定为部署问题（deployment issue）而非产品漏洞。

结合源码可以看到这条规则的典型适用场景：

• 直接把未启用 TLS 的实例暴露到公网后被嗅探（对应“生产环境使用 TLS”建议）；
• 把端口绑定到外部网卡且关闭了认证访问控制（官方 Docker 快速上手默认绑定 127.0.0.1，见上文）；
• 自建反向代理时错误地透传 Origin，破坏 server/cors.go 中“可信 Origin 才带凭证”的判定；
• 应用官方不维护的本地补丁后出现的回归。

换句话说，官方安全边界是“产品按默认/建议方式部署时”的行为；偏离该边界产生的风险由部署者承担。撰写报告前，对照上面的五条基线自查一遍，可以明显减少被归类的摩擦。

小结与行动清单

事项	依据	行动
仅最新发行版获得安全修复、不 backport	SECURITY.md	将升级纳入例行运维，跟踪 CHANGELOG.md
漏洞走私密邮件，禁止公开 issue/PR	SECURITY.md	按五项清单（描述/复现步骤/版本或 commit/部署细节/影响评估）提交至 [e-mail]
无正式披露流程、无 CVE	SECURITY.md	合规台账自行维护版本与 changelog 映射
反向代理 + InstanceURL 配置	SECURITY.md、server/cors.go	代理正确传递 Host/Origin，配置并校验 --instance-url
认证与 TLS	SECURITY.md、server/auth/token.go、README.md	启用认证、生产启用 TLS、收敛用户与 Space 成员
部署问题 vs 产品漏洞	SECURITY.md	报告前按五条基线自查，剔除“故意不安全”因素

适用前提：本文结论基于当前仓库快照（Go 1.27 工具链，见 go.mod）与 SECURITY.md 描述的 0.x 支持策略；若项目进入 1.x 或启用正式披露流程，以上版本支持与 CVE 相关结论需要以届时文档为准。