.webp){kind=small}
浏览器怎么判断是不是同一个网站：Origin、Site 与同源策略
浏览器通过Origin和Site两个标准判断请求归属：Origin由协议、主机和端口组成（如https://api.example.com:443），仅路径不同也算同源；Site则基于协议和可注册域名（如github.com），不同端口或子域名可能同站。同源策略限制脚本跨源读取数据、Cookie、localStorage等敏感资源，但允许跨源图片、表单提交等非敏感请求。SameSite策略通过判断站点边界控制Cookie跨域发送，需结合Public Suffix List识别可注册域名（如www.example.com与example.com同站）。常见误区包括：跨源不一定跨站（如不同端口下同站）、同源策略不阻止跨源请求到达服务器（主要限制脚本读取）、Node.js等后端环境不受同源策略限制。正常逻辑流程：同源需协议、主机、端口一致；同站需协议+可注册域名相同。浏览器核心执行文档中需强调SameSite与同源策略的区分，避免混淆CORS防护边界和同站逻辑设计。
Cookie 为什么会自动携带：Session、HttpOnly、Secure 与 SameSite
浏览器基于域名、路径和Cookie标记决定是否自动携带 Cookie，Session管理核心仍需依赖服务端。安全配置需组合使用Secure（强制HTTPS）、HttpOnly（阻止JS窃取）和SameSite（默认Lax即同源携带，跨源不跟随），其中SameSite=S glBegin不能替代CSRF Token。推荐使用__Host前缀配置，需同时满足Secure+Path=/+无Domain设置，这种模式兼具跨子域名限制和同源容错优势。与localStorage相比，Cookie虽能通过HttpOnly防御XSS直接读取，却仍需配合其他机制防范CSRF和漏洞利用。常见陷阱包括误认为HttpOnly可禁用Cookie发送、SameSite=Lax可替代认证Token、Path即可实现权限隔离，正确配置需严格遵循安全原则与服务端权限验证结合。
浏览器 Web 安全基础系列：从同源策略到 XSS 与资源防护
本系列系统讲解浏览器安全机制，按依赖关系设计学习路径，先从同源策略、网站指纹识别基础，逐步深入Cookie存储规则、跨源资源共享（CORS）限制原理，解析XSS攻击路径与防御方法，最后拓展至内容安全策略（CSP）、第三方资源完整性验证及防盗链机制。内容围绕单次HTTP请求展开，完整解析浏览器安全防护流程：同源判断→Cookie携带→CORS拦截→服务端登录状态校验→XSS过滤→安全策略执行。适合具备HTML/JavaScript基础但未系统学习Web安全的前端开发者，每篇通过真实场景问题引入，搭配核心代码解析与可运行实验验证，特别标注常见误区（如同源策略≠CORS限制）。系列边界聚焦浏览器安全层，不延伸SQL注入等服务端漏洞。建议按01-08建立基础模型，09-11深入防御，最后12篇综合策略应用，概念混淆时可回溯特定篇目对照练习。
KMS与HSM：从密钥管理原理到企业选型方案
KMS（密钥管理服务）与 HSM（硬件安全模块）共同解决密钥全生命周期管控，但分工明确：KMS 负责密钥权限、审计、轮换及短期存储管理；HSM 提供硬件级密钥生成、加密运算及不可导出特性，确保密钥物理隔离。密钥采用分层结构，主密钥（如 CMK）加密数据密钥（DEK），业务数据通过信封加密实现高效处理与最小化 KMS 负载。选型需综合威胁模型（如防范内部泄露或物理攻击）、合规要求（国密算法认证、独立灾备及双人操作）、性能（低延迟调用、批量接口）、集成能力（兼容 API/SDK/HSM）及成本（专属 resources 对高价值场景必要）。核心风险防范包括：避免密钥硬编码在代码/镜像，禁止一种密钥完成所有操作（如加密+签名），及时记录密钥版本与 Nonce，轮换后保留旧密钥恢复历史数据，杜绝 HSM 仅依赖硬件安全。落地前需验证密钥隔离边界、审计深度、灾备恢复演练及权限精确到密钥粒度，确保系统通过必要认证（如 FIPS 140-3），并避免中断业务连续性的操作。
