Web 应用安全基础涉及浏览器执行权限、跨站请求、会话凭据和客户端存储的边界。前端校验有助于交互，但服务端仍需验证身份、权限和输入。
XSS
跨站脚本攻击让攻击者控制的内容在目标站点上下文中执行。应区分文本、HTML、URL 等输出位置，使用相应安全处理；展示普通文本时优先使用文本接口。框架默认转义不能保护主动插入原始 HTML 的位置。
富文本需要可信的净化方案；内容安全策略可作为额外防线。HttpOnly 只能阻止脚本直接读取对应 Cookie，无法阻止已运行的恶意脚本利用当前页面权限发请求或读取其他可访问数据。
参考：XSS 官方说明。
CSRF
跨站请求伪造利用浏览器在某些请求中自动携带凭据的行为，诱导用户以已登录身份执行操作。防护可结合 CSRF token、Origin 等来源验证和合理的 SameSite Cookie 策略；状态改变操作不应依赖 GET。
同源与同站是不同概念。CORS 也不等于 CSRF 防护：某些跨源请求可以发出，即使脚本读不到响应，服务器仍可能执行操作。
参考：CSRF 官方说明。
Cookie 与会话
Cookie 可以按域、路径、安全连接及 SameSite 等规则随请求发送。Secure 限制安全传输条件，HttpOnly 限制脚本访问，SameSite 约束跨站发送场景。SameSite=None 通常还要求 Secure。
会话失效、服务端撤销、刷新策略和权限校验属于完整登录方案的一部分。仅在前端删除一个标记，并不一定撤销服务端会话。
参考：HTTP Cookie 官方指南。
Web Storage
localStorage 按源保存，通常可跨浏览器会话保留；sessionStorage 还按顶层浏览上下文划分，通常随对应标签页会话结束。两者提供同步的字符串键值访问，不会像 Cookie 那样自动加入每次 HTTP 请求。
同源脚本可读取 Web Storage，因此不能把它视为防 XSS 的秘密保险箱。凭据存放方案应结合攻击面和架构判断，不能单凭“Cookie”或“token”名称判断安全性。
参考：Web Storage 官方参考。