html中敏感字段明文暴露必然被爬，安全做法是不在初始html渲染敏感数据，须通过校验登录态和风控的动态接口获取，css伪元素、unicode混淆仅防低配爬虫，js动态加载非银弹，所有校验必须在服务端。

HTML里直接写敏感字段等于白给

只要邮箱、手机号、商品ID、API路径这些字符串明文出现在或<script></script>里，爬虫用requests.get()加BeautifulSoup就能秒提——连JS都不用执行。这不是“可能被爬”，而是“必然被爬”。

常见错误现象：

• 把user_id=123456硬编码在<div data-id="123456">里<li>在<code><script></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这类强敏感字段。


Wechat HTML Publisher
直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。
下载

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的代码混淆强度、以及服务端返回数据的字段脱敏策略。漏掉任意一环，防护就形同虚设。