HTML中敏感字段明文暴露必然被爬，安全做法是不在初始HTML渲染敏感数据，须通过校验登录态和风控的动态接口获取，CSS伪元素、Unicode混淆仅防低配爬虫，JS动态加载非银弹，所有校验必须在服务端。
HTML里直接写敏感字段等于白给
只要邮箱、手机号、商品ID、API路径这些字符串明文出现在<body>或<script>里，爬虫用requests.get()加BeautifulSoup就能秒提——连JS都不用执行。这不是“可能被爬”，而是“必然被爬”。
常见错误现象：
- 把
user_id=123456硬编码在<div data-id="123456">里 - 在
<script>中塞内联JSON：var price = 299.00; - 用
<!-- order_no: ABC789 -->注释藏关键信息
这些全算明文，静态扫描工具一扫就出。真正安全的做法只有一条：**不在初始HTML里渲染敏感数据**。哪怕只是展示，也得走fetch动态拉取，且接口必须校验登录态和风控维度（如设备指纹、请求频率）。
CSS伪元素拼接只防正则，不防真爬虫
用::before/::after把价格拆成几段再拼，确实能绕过re.findall(r'\d+\.\d+', html)这种基础正则提取，但对真实爬虫无效。
立即学习“前端免费学习笔记（深入）”；
原因很直接：
-
window.getComputedStyle(el, '::before').content可直接读取伪元素内容 - Puppeteer/Playwright这类工具能完整执行JS并获取渲染后DOM
- 如果拼接逻辑写死在CSS里（比如
content: "¥" "2" "9" "9";），爬虫静态解析CSS文件就能还原
适用场景仅限于：对抗低配规则爬虫、降低自动化采集ROI。别把它当防线，更别用它处理用户ID、token这类强敏感字段。
Unicode同形字混淆要小心字体和粘贴兼容性
把阿拉伯数字123换成全角１２３、拉丁字母a换成西里尔а，能干扰OCR和简单字符串匹配，但坑不少：
- 部分终端/屏幕阅读器不支持渲染，导致可访问性失效
- 用户复制粘贴时，可能带出不可见控制字符或乱码
- 移动端缩放后字形模糊，尤其小字号下识别率骤降
- 某些字体（如系统默认等宽字体）会把同形字显示为方块
实操建议：
- 只用于非交互型文本（如价格、评分），禁用于输入框placeholder或表单提交值
- 测试主流字体（Noto Sans、PingFang、Segoe UI）下的渲染一致性
- 搭配
font-feature-settings: "liga" off;禁用连字，避免意外合并
JS动态加载不是银弹，反而暴露更多攻击面
把数据从服务端API里fetch回来再innerHTML写入，看起来安全了？其实只是把战场从前端搬到了JS层。
容易踩的坑：
-
fetch的URL和参数若写死在JS里（如fetch('/api/order?id=' + id)），会被grep -r "/api/order"直接扫出 - 密钥、token写在前端代码里，等于公开分发
- 没做Referer/User-Agent校验的接口，Puppeteer伪造浏览器环境就能调通
真正难绕过的只有服务端逻辑：数据库查询条件、风控规则、会话上下文。所有校验必须留在后端——前端JS只是个展示层，不该承担任何权限判断。
复杂点在于：你得同时管住三件事——API接口的鉴权粒度、前端JS的代码混淆强度、以及服务端返回数据的字段脱敏策略。漏掉任意一环，防护就形同虚设。
