心理数据后台登录后通常使用Token或Session ID维持会话。若把会话凭证存入localStorage，同源JavaScript就能够读取它；页面一旦出现XSS漏洞，凭证可能泄露。
XSS的风险不限于窃取令牌。恶意脚本还可能读取页面中的健康资料、修改界面，或以当前用户身份执行操作。第三方组件和富文本内容都需要适当的安全处理，不能只靠更换存储位置解决。
对于适合使用Cookie维持会话的应用，HttpOnly、Secure和合适的SameSite配置可以降低部分风险，但各自有不同作用和限制。
HttpOnly限制脚本读取会话Cookie
HttpOnly使Cookie不通过document.cookie等脚本接口暴露。它降低会话Cookie被脚本直接读走的风险，并不阻止恶意脚本运行。
服务端可以在登录响应的Set-Cookie中设置会话Cookie。下面仅为属性示例，凭证值必须由服务端安全生成：
Set-Cookie: SESSIONID=example-session-value; Path=/; HttpOnly; Secure; SameSite=Lax浏览器仍会在符合Cookie规则的请求中携带会话信息。即使脚本读不到Cookie，恶意同源脚本也可能发出已认证请求。因此还需处理不可信输入、按上下文编码输出、清洗允许的富文本，并维护依赖安全；内容安全策略可作为附加防线。
SameSite减少部分跨站请求风险
CSRF利用浏览器可能自动携带Cookie的行为，诱导已登录用户发出非本人意愿的请求。风险是否成立，取决于请求方式、Cookie配置以及服务端防护，不能笼统说跨站表单一定会成功。
SameSite=Strict限制跨站请求携带Cookie，通常也会影响从外部链接进入应用时的登录体验。Lax允许部分顶层安全方法导航；None用于允许跨站携带，并须配合Secure。应根据登录、跳转和集成流程测试选择。
Set-Cookie: SESSIONID=example-session-value; Path=/; HttpOnly; Secure; SameSite=Strict“同站”不等于“同源”。现代浏览器判断站点时考虑协议和可注册域，不要求子域名完全一致；同源还涉及主机名和端口。一个同站子域受到攻击时，不能指望SameSite自动阻断所有请求。
服务端仍需完整防护
对修改数据的请求，优先使用框架提供的CSRF防护，或按架构正确验证CSRF令牌、Origin及Fetch Metadata等信息；GET等安全方法不应修改状态。还需服务端授权检查、会话失效机制和XSS防护。Cookie属性是其中几层措施，不能单独保证后台安全。