基于libsodium实现JS前端与Python后端API密钥加解密方案咨询

加密方案选型（对应问题4） #

直接选libsodium的公钥加密（crypto_box_seal 匿名密封箱）方案，不要用对称加密。
对称加密的核心硬伤是需要前后端持有同一把密钥，不管你是把密钥硬编码在JS里、接口下发还是做代码混淆，前端用户都能直接拿到密钥，前端加密层完全等于摆设。而公钥密封箱方案从设计上规避了这个问题：后端自己持有永不外泄的私钥，仅对外公开公钥，前端用公钥加密的内容只有后端能解密，公钥本身就算被所有人拿到也不影响安全性，根本不需要解决“前后端安全共享密钥”的伪问题。

对称加密的密钥共享问题解答（对应问题1） #

不存在安全的前后端对称密钥共享方案。
所有你能想到的对称密钥下发路径——不管是写死在前端代码、页面渲染时注入、单独接口拉取——都能被访问页面的用户直接获取，拿到密钥的人可以随意解密所有传输的密文，加密完全失去意义。这也是为什么必须换公钥加密方案，根本不需要共享敏感密钥：

• 后端私钥全程只存在服务端，绝不对外返回
• 前端只需要拿公开的公钥做加密，公钥不需要保密，随表单页面一起下发或者单独接口返回都可以

业务流程合理性校验（对应问题2） #

• ① 「前端加密后仅传密文、后端直接存密文入库」的流程不正确。
  前端加密用的公钥是公开的，攻击者如果拿到用户的访问权限，完全可以自己用公钥加密任意内容替换用户存储的密文，后续调用Cloudflare时就会使用攻击者提交的内容，存在越权和逻辑漏洞。
  正确流程：后端收到前端传来的密文后，先用持有的私钥解密得到明文API密钥，先做合法性校验（比如Cloudflare密钥固定前缀、长度校验），确认格式合法后，用后端本地存储的对称密钥对明文做二次加密，最后把二次加密的密文存入数据库。
• ② 「调用Cloudflare时从数据库读密文、解密后用明文调用接口」的流程基本正确，补两个安全细节：解密得到的明文密钥只存在当前请求的内存里，用完立刻清除，绝对不要写入日志、不要存在全局变量中长期驻留；不要把明文密钥返回给前端。
• ③ 绝对不能解密完整密钥回填到输入框。你提到的「仅展示最后4位、其余打星号掩码，用户修改时直接全量输入新密钥走首次提交流程」是行业通用的正确做法。额外提一句：密钥后4位可以单独作为明文字段存在数据库里，不需要每次展示的时候都解密完整密钥，减少明文暴露的机会。

nonce与密钥的生成、存储规则（对应问题3） #

所有密钥和参数按以下规则生成、存储，不要混放：

• 后端公钥加密私钥、后端二次加密用的对称密钥：服务部署时通过环境变量注入，或者首次启动服务时生成后存储在服务器本地权限严格控制的密钥文件中（仅服务运行用户可读），绝不存入数据库、绝不对外返回
• 前端加密用的公钥：用户打开表单页面时由后端动态返回，前端不需要持久存储，每次打开页面拉取最新的即可
• 前端加密用的nonce：每次用户提交表单、前端执行加密操作前，通过libsodium.js的randombytes_buf当场随机生成，不需要提前存储，加密后把nonce和密文拼接后一起传给后端即可（nonce不需要保密，只需要保证每次加密使用的nonce唯一）
• 后端二次加密用的nonce：后端校验完明文密钥合法性、执行二次加密前当场随机生成，和二次加密后的密文拼接后一起存入数据库即可，同样不需要保密。

额外提醒：前端加密不能替代HTTPS，所有表单提交必须走HTTPS协议。前端加密的作用是降低数据库拖库、链路日志泄露导致的批量密钥泄露风险，HTTPS是保障传输链路安全的基础，两者缺一不可。

内容的提问来源于stack exchange，提问作者Kim Stacks