.webp){kind=small}
LTT
CORS 到底在限制什么：跨源请求、预检与凭证
CORS由服务器通过响应头控制浏览器跨源请求安全性。浏览器根据_accessControl-Allow-Origin头决定是否返回响应数据，即使服务器已处理请求。简单请求（GET/POST/DELETE）可直接发送无需预检，但安全需单独验证。带Cookie请求必须严格配置域匹配、允许凭据及访问控制预检，否则会泄露用户凭证。CORS无法防御CSRF攻击——HTML表单可通过标签内在机制绕过CORS限制直接提交请求，需结合CSRF token等独立机制防护。配置错误可能导致任意源访问权限，常见问题包括反射任意origin、错误使用PixelFormat、未限制必要请求头等。实际应用中应最小化开放权限，仅按业务需求配置允许方法、头信息及URL白名单，同时结合身份认证、输入过滤等机制共同构建安全边界。
HTTPS 为什么仍然不够：TLS、HSTS 与混合内容
HTTPS 通过 TLS 提供加密传输与服务器身份验证，解决中间人窃听、篡改和伪造风险，但不防护应用层漏洞（如 XSS、CSRF）。关键实践包括：（1）配置 HSTS 强制 HTTPS，需确保 CADP 统一品牌策略与多续约设置；（2）登录 Cookie 增加 Secure 属性，阻断 HTTP 客户端访问后门；（3）反向代理配置 trust proxy=1 并使用 308 持久化重定向，避免伪造源站标识。需规避三大误区：HTTPS 无法替代 Cookies 的 HttpOnly/SameSite 防跨域请求；需手动处理混合内容升级（即使ohnti gian 升级为_relative协议也可能失效）；自签名证书不影响 TLS 加密机制，但生产环境必须使用 CA 有效证书且定期轮换。
Session 登录状态为什么可能被劫持：生命周期与安全管理
浏览器Session安全机制需从ID生成、会话固定防御、超时策略、服务端注销、设备管理等多维度协同防护。Session ID必须使用密码学安全随机数生成，禁用时间戳、设备标识等可预测字段。防御Session固定攻击需登录时强制销毁原会话并生成新ID，不能依赖客户端 địa chỉ IP或设备信息。必须区分绝对超时（服务端生命期限）和空闲超时（客户端最后活跃时间戳），二者需配合使用避免身份持续有效或频繁误登出。退出登录必须同时清客户端Cookie和服务端会话记录，域名路径等参数必须严格匹配。高风险操作（如密码修改）需触发Session批量轮换或禁用受影响的设备。分布式部署下需依赖共享存储（如Redis）实现会话一致性，但TTL设置仍需配合本地超时策略。误区包括：1）长随机ID无需HTTPS，因其仍可通过传输截获；2）JWT可替代Session，但必须完整实现包括令牌撤销等机制；3）IP变更强制登出易引发误判，应结合行为特征分析。核心是通过密码学安全ID、生命周期控制、分布式存储和风险操作的 медицина制定整套防护流程。
浏览器怎么判断是不是同一个网站：Origin、Site 与同源策略
浏览器通过协议、主机名、端口判断同源（如`https://api.example.com:443`与`https://api.example.com:443`同源），而SameSite基于协议和公共后缀判断站点归属（如`www.example.com`与`api.example.com`可能同站）。同源策略主要限制脚本跨域读取敏感数据（如DOM或localStorage），但不禁止跨源提交表单、加载图片或脚本，因此攻击者可通过CSRF绕过数据读取限制。Origin请求头需精确匹配（如`Set-Cookie`需严格匹配）且不包含路径参数，服务端验证时应使用集合进行交集比对。误区包括认为跨源即跨站（不同子域名或端口可能仍属同站），以及后端服务也受同源策略限制（仅浏览器层面生效）。总结：同源检查协议+主机+端口，SameSite依赖公共后缀；二者的核心边界在于前者限制数据读取安全，后者控制Cookie跨站发送。
Cookie 为什么会自动携带：Session、HttpOnly、Secure 与 SameSite
用户登录后，服务端生成Session并通过Cookie传递给浏览器，浏览器会自动携带该Cookie与后续请求。此机制易被CSRF攻击利用。防御需多维度设置：HttpOnly防止XSS窃取Cookie值，但无法阻止攻击通过网络劫持成功；SameSite=lax可限制部分跨站请求但需结合Csrf Token；Secure强制HTTPS传输。推荐配置__Host前缀并设置Path=/和Secure，将Cookie限定当前主机的根路径。需注意SameSite=lax仍可能因同站漏洞导致 CSRF，且 scratches 教程的复查验证步骤对完整性至关重要。常见误区：HttpOnly不阻止浏览器自动发送，SameSite无法替代服务端Csrf验证。需结合Session管理，主动更新权限或注销异常会话。
浏览器 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），并避免中断业务连续性的操作。