你用手机转账时，银行App为啥不直接把密码明文发给服务器？微信聊天记录为啥别人截不到原始内容？这些背后，靠的不是玄学，而是安全协议设计的一套实打实的原则。
1. 最小权限：能少传，绝不多给
协议不该索取它不需要的信息。比如登录接口，只要验证身份，就别顺手把用户通讯录、相册路径也一起带上。HTTP Basic Auth 曾经把用户名密码 Base64 编码后塞进 Header，看似“编码”了，实则等同明文——这违背了最小权限，也暴露了保密意识的缺失。
2. 深度防御：别把鸡蛋放一个篮子里
单靠 TLS 加密不够，单靠签名也不保险。真实系统里，TLS 保传输，HMAC 防篡改，时间戳+随机数防重放，三者叠在一起才扛得住常见攻击。就像你家门锁+防盗链+智能门铃，每层不一定完美，但叠加起来让小偷多花十倍时间。
3. 明确状态：协议必须知道自己在哪个阶段
很多协议漏洞出在状态混乱上。比如 TLS 握手没完成就允许发送应用数据，或者认证失败后还保留会话上下文。理想状态下，每个消息都该带明确的状态标识：
{"stage": "handshake", "step": "key_exchange", "nonce": "a7f2e1..."}4. 失败要安静：别当漏洞情报员
错误提示不是越详细越好。登录失败时返回“用户名不存在”和“密码错误”，等于帮攻击者枚举账号；API 返回 500 并附带堆栈跟踪，可能泄露框架版本甚至路径结构。安全协议的错误响应应统一、模糊、无差别：
HTTP/1.1 401 Unauthorized\n{\n "error": "auth_failed"\n}5. 可审计、可替换：别写成黑盒魔法
用自研加密算法代替 AES？用自己写的随机数生成器替代 /dev/urandom？这类“我觉得更安全”的操作，往往是灾难起点。协议设计要默认支持标准算法插拔，比如 TLS 1.3 允许协商 ChaCha20-Poly1305 或 AES-GCM；密钥生命周期要清晰可查，轮换机制写进协议流程，而不是靠运维半夜手动改配置。
安全协议不是越复杂越牢靠，而是越清晰、越克制、越经得起推敲，越能在真实网络里活下来。