Beego中安全暴露RSA公钥应通过登录预加载页动态注入，绑定session或nonce，公钥从内存缓存或带过期/分片的Redis读取；前端须用WebCrypto配合RSA-OAEP、Uint8Array明文和base64url编码；后端解密需指定SHA256哈希且不暴露错误细节；因RSA限长，应采用RSA加密AES密钥+AES-GCM加密业务数据的混合模式，并将timestamp和nonce作为AAD保障防重放。
Beego 中如何安全暴露 RSA 公钥？
公钥不能硬编码在前端或配置文件里，更不能通过 /api/pubkey 这类无鉴权接口直接返回——攻击者可批量抓取并用于伪造请求。Beego 下推荐做法是：在登录前的「预加载页」（如 /login GET 接口）中，由后端动态注入公钥，且绑定当前 session 或一次性 nonce。
实操建议：
- 用
beego.Controller.Data["PublicKey"]将 Base64 编码的 PEM 公钥传给模板，避免 XSS 风险； - 公钥内容需从服务端内存缓存（如
sync.Map）读取，而非每次读文件——文件 I/O 在高并发下易成瓶颈； - 若使用 Redis 存储公钥，务必设置过期时间（如 24h），并配合 appId 或 clientType 做 key 分片，防止密钥污染。
前端用 WebCrypto 加密密码时踩了哪些坑？
Beego 默认不干预前端逻辑，但很多团队直接用 jsencrypt 库，结果在 Safari 或新版 Chrome 上解密失败——根本原因是 RSA 密钥格式和填充模式不兼容。
关键点：
- 服务端生成密钥必须用
RSA-OAEP（非 PKCS#1 v1.5），否则 WebCrypto 的importKey会报OperationError； - 前端加密前，明文必须转为
Uint8Array，不能直接传字符串——new TextEncoder().encode("123456")是必须步骤； - 加密后得到的 ArrayBuffer 要用
base64url（非 base64）编码再发到后端，否则 Beego 的GetString会截断 + 号。
Beego Controller 怎么安全解密 RSA 密文？
别在每个 action 里重复写解密逻辑，也别把私钥明文塞进 controller 结构体——私钥一旦泄漏，整个加密体系就崩了。
正确姿势：
- 私钥加载走
beego.AppConfig.String("rsa::private_key_path")，路径指向受权限控制的只读文件（如0400）； - 用
crypto/rsa+crypto/rand解密，必须显式指定&rsa.OAEPOptions{Hash: crypto.SHA256}，否则默认用 MD5（已不安全）； - 解密失败时统一返回
400 Bad Request，不要暴露是密钥错、padding 错还是数据被篡改——避免给攻击者侧信道信息。
为什么登录接口不能只加 RSA，还得套一层 AES？
RSA 本身不适合加密长文本（比如含扩展字段的 JSON），2048 位密钥最多只能加密 245 字节（OAEP 模式）。而 Beego 的登录参数往往不止密码，还带 username、captcha、device_id 等，一超限就解密失败。
真实项目中更合理的做法是混合加密：
- 前端生成随机 AES-256 密钥，用 RSA 公钥加密后传给后端（放 header 或 body 的
enc_key字段）； - 业务数据（如
{"username":"a","password":"b"}）用该 AES 密钥加密，走标准AES-GCM模式； - Beego 后端先用 RSA 私钥解出 AES 密钥，再用它解 GCM 密文——这个流程必须原子化，中间任何一步失败都应丢弃全部请求。
最容易被忽略的是 GCM 的 AAD（附加认证数据）：必须把 timestamp 和 nonce 一起喂进去，否则防重放机制就形同虚设。
