5.安全防护场景题
查看飞书原文 ↗4,838 字符
开场话术
"前端安全不只是防XSS，需要建立完整的安全防护体系。"
"我们从代码层面到部署层面都做了安全加固。"
标准答题示例
我们的金融类应用对安全要求很高，我负责前端安全防护设计。
XSS防护方面：
•
所有用户输入都做HTML转义，用DOMPurify过滤危险标签
•
使用CSP策略限制脚本执行，阻止内联脚本
•
建立了安全编码规范，禁止使用innerHTML等危险API
CSRF防护：
•
所有状态变更请求都带CSRF Token
•
用SameSite Cookie属性限制跨站请求
•
关键操作增加二次验证，比如短信验证码
数据安全：
•
敏感数据前端不存储，用完即清
•
localStorage存储用AES加密
•
建立了数据脱敏规范，日志中不出现敏感信息
部署安全：
•
启用HTTPS和HSTS，强制安全连接
•
用Webpack的代码混淆，保护知识产权
•
建立了安全扫描流程，每次发布前自动检测漏洞
监控告警：
•
用Sentry监控前端异常，异常行为及时告警
•
建立了用户行为分析，识别潜在的攻击行为
这套安全体系上线后，0安全事故，通过了等保三级认证。
常见追问及应对
面试官： “XSS攻击具体有哪些类型？你们是怎么防护的？”
📔
答题思路：展示你对 XSS 类型划分的清晰理解，并结合代码解释防护机制的覆盖广度与落地方案。
XSS 攻击主要分为三类，我们在编码和配置层面都做了相应防护。
存储型 XSS（Stored XSS）
攻击者将恶意脚本注入数据库，其他用户在访问时触发执行，危害最大。
const maliciousComment = '<script>stealCookies()</script>';防护措施：
•
后端入库前使用白名单规则清洗（如 DOMPurify）；
const sanitizedHtml = DOMPurify.sanitize(comment.content, {
ALLOWED_TAGS: ['b', 'i', 'strong', 'p'],
ALLOWED_ATTR: ['class'],
});
•
前端渲染采用 dangerouslySetInnerHTML 时进行明确的 HTML 过滤；
•
React 默认 JSX 是安全的，除非使用未经过滤的dangerouslySetInnerHTML属性：
<div dangerouslySetInnerHTML={{ __html: userInput }} />
反射型 XSS（Reflected XSS）
攻击者构造恶意链接，通过 URL 参数注入脚本，通常结合钓鱼页面使用。
// URL: http://xx.com/search?q=<script>alert('xss')</script>防护措施：
•
对 URL 参数做 HTML 编码；
•
使用 Content-Type: application/json 避免服务端直接渲染输入；
•
React、Vue 默认会自动对变量内容转义。
DOM 型 XSS（DOM-based XSS）
攻击不依赖后端，直接在前端通过 innerHTML 或 eval 等危险 API 插入脚本。
// 安全写法：textContent 替代 innerHTML
element.textContent = userInput;
React 特性：
React 本身默认做了内建转义（除非使用 dangerouslySetInnerHTML），非常适合构建防 XSS 的应用。
CSP（内容安全策略）补充防线：
借助 HTTP 头控制脚本来源、内联限制、数据加载等，是防御 XSS 的最后一道防线。
<meta http-equiv="Content-Security-Policy" content="
default-src 'self';
script-src 'self' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
connect-src 'self' https://api.example.com;
" />
上线时我们还配置了 CSP 违规监控（结合 securitypolicyviolation 事件）便于追踪异常加载行为。
面试官： “CSRF攻击的原理是什么？如何防护？”
📔
答题思路：说明攻击原理后，系统性覆盖前后端防御手段，并强调组合使用的重要性。
CSRF 本质上是“借用用户的登录态，在用户不知情的情况下，诱导其发起敏感请求”。
攻击示意：
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="attacker">
</form>
防护手段一：CSRF Token 机制（主流方案）
•
服务端在会话中生成 csrf_token；
•
前端每次请求时在 Header 或 body 带上该 token；
•
后端验证 token 与 session 是否匹配。
config.headers['X-CSRF-Token'] = csrfToken;在 React 项目中我们封装了 useCSRFProtectedRequest，自动添加 token。
防护手段二：SameSite Cookie 属性
通过设置 Cookie 的 SameSite=Strict，限制第三方页面带 cookie 请求，阻断大多数 CSRF 攻击。
cookie: {
sameSite: 'strict',
secure: true,
httpOnly: true
}
防护手段三：关键操作二次验证
我们对转账、修改密码等高危行为引入短信验证码 / 动态令牌验证，增强事务完整性
{isVerifying && <VerificationCode onConfirm={confirmTransfer} />}
防护手段四：Referer 校验（兼容兜底）
用于校验请求来源域名，防止非法页面发起跨域敏感请求。
return referer?.startsWith('https://mybank.com');
我们在线上系统中实际组合使用了以上机制，确保即使某一机制失效，攻击也无法成功。
面试官： “敏感数据在前端如何保护？”
📔
答题思路：说明你理解“前端不可信”的前提，重点在数据控制、加密、安全传输与临时存储处理。
我们从“只给必要数据”到“存储加密”、“运行中清理”等多个维度来保护前端的敏感信息。
最小数据原则（减少暴露）
后端接口只返回展示所需字段，敏感字段不暴露，或者做掩码处理。
email: maskEmail(user.email); // u***@example.com
本地数据加密存储
我们封装了一个 AES 加密的 localStorage 工具类，所有缓存的 token 和用户信息都加密后再存储。
CryptoJS.AES.encrypt(JSON.stringify(value), secretKey).toString()
内存清理机制
用户提交支付信息等高敏感数据后立即清空状态，并在组件卸载时再做清理。
useEffect(() => () => {
setCardNumber('');
setCvv('');
}, []);
数据传输保障
所有接口强制 HTTPS，axios 请求中添加了常用安全头部，防止缓存、钓鱼或跨协议攻击。
headers: {
'X-Requested-With': 'XMLHttpRequest',
'Cache-Control': 'no-cache'
}
开发者工具检测（弱保护）
虽然不能完全防止调试，但我们仍提供了浏览器窗口尺寸监测脚本，一旦发现 DevTools 打开，可清空敏感数据并跳转安全页。
window.outerHeight - window.innerHeight > threshold
整体原则是：能不传就不传，必须传就加密传，传完立刻删。
面试官：“如何建立前端安全监控体系？”
📔
答题思路：展示你理解“检测 + 响应 + 告警”闭环，并从用户行为、DOM变化、CSP违规等多角度布防。
我们建立了一个分层的前端安全监控体系，核心包括：
异常行为监控
使用请求拦截器统计短时间内的请求次数，识别可能的脚本攻击。
if (requestCount > 50) {
this.reportSecurityEvent({ type: 'suspicious_request_frequency' });
}
同时监听 DOM 插入行为，监测是否有未授权脚本动态注入。
if (element.tagName === 'SCRIPT' && !element.getAttribute('data-approved')) ...
CSP 违规监控
通过监听 securitypolicyviolation 事件，实时上报 CSP 拦截的脚本或样式来源。
document.addEventListener('securitypolicyviolation', ...)这对防止 CDN 被替换、外链脚本注入非常有效。
错误监控与分类分析
使用 Sentry 统一上报安全相关异常，添加 security 标签，支持后续分类统计与告警。
event.tags = { ...event.tags, security: true };
我们还会添加自定义 breadcrumb，记录异常前的用户行为路径，帮助定位问题根源。
实时告警机制
通过 WebSocket 接入公司安全后台，监听高危事件，如脚本注入、暴力请求等。
高危告警会立即清空用户存储，锁定 session，跳转到安全提示页。
window.location.href = '/security/locked';这套体系上线后曾成功检测并阻止过一次存储型 XSS 攻击尝试，攻击者插入的脚本在 CSP 和 DOM 监控下被实时封堵，并在 15 分钟内上报后台完成审计。
💡 整体答题策略
1.
了解OWASP Top 10：熟悉Web安全的主要威胁和防护措施
2.
准备安全工具：了解CSP、HSTS、SRI等安全机制的配置和使用
3.
关注法律法规：了解数据保护相关的法律要求，如GDPR、网络安全法等
4.
准备实际案例：最好能举出处理过的真实安全事件或漏洞修复经验