一切的前端安全都是纸老虎

引子

最近逼乎有一个很火热的问题，叫前端可否限制用户截图？

当我看到这个问题，我就以为这个提问者应该是个萌新，或者已经被产品经理或SB leader 折磨的失去理智。由于下方有一个很是直中要害的回答：

不管多么牛的技术手段限制了软件的截图, 用户只要简单的掏出手机对着屏幕拍照就行了。

这个问题，真的说明一切的前端安全，其实都是纸老虎。

接下来，我结合本身遇到的几个场景，来谈一些作前端以来，本身遇到的那些伪前端安全需求。

曾经那些被怼回去的安全需求

最近几年互联网数据泄露很是频繁，我上一家公司是作金融贷款的，很是强调数据安全，这两年也作了很多关于安全的需求。

前端数据脱敏

前端数据脱敏是一个很常见的需求，特别是当今隐私被卖的这么猖狂的时代，因此不少公司都开始注重这些细节，最基础的就是数据脱敏。

数据脱敏，就是将用户的隐私信息，用一些手段，让这些信息有必定辨识度，但又没法准确获取，好比：

• 金*胖
• 186**2892
• 510*1262
• 川A 7*1

上面通常是咱们常见到的数据脱敏格式，我又叫他数据马赛克。前端能不能作，确定能作，一个正则配上一个String.replace方法就搞定。但若是产品让咱们实现这种需求，咱们确定要拒绝，由于前端作数据脱敏就是被单里眨眼睛 - 自欺欺人。

归根揭底，一个稍微有点IT常识的人，若是想要这些数据，直接从请求拿就是了，何须从页面复制。

因此数据脱敏这种事，必定要交给后端作，从源头开始脱敏。

可能后面一些场景，有些被脱敏的数据，在前端又要被用到。好比列表数据脱敏，到详情/表单编辑操做时又须要脱敏前的，那就根据ID再发一次请求获取脱敏前的数据，而后对这个接口调用作权限限制和日志记录，让敏感数据的使用相对安全。

表单校验是为了安全么

咱们在作表单时，不少时候都会针对数据格式作校验，好比邮箱、电话号码、银行卡号这些，甚至还有一些很是复杂的联动校验。

前端作校验是为了安全么？

可能有那么一丁点意思吧，好比之前咱们老是在提校验输入防XSS攻击。但如今前端这种格式校验，更可能是为了：提高用户体验,提高用户体验,提高用户体验。

• 首先提醒并引导用户，应该怎么输入；
• 其次，若是用户输入半天，前端不校验，直接到后台，后台发现格式不正确，再提示用户，这是一个很是耗时且不专业的交互体验；
• 若是前端没校验，后端也没校验，那这就是一条脏数据插入到数据库，有可能形成XSS攻击 或 SQL攻击, 这就很是危险了。

数据报表加水印

页面加水印，其实在前端很广泛，好比钉钉, 企业微信 的群聊都是加了水印的，不少在线图片编辑工具也是加了的，好比我经常使用的图怪兽，你想白嫖，他就给你加个水印：

而当时咱们有些列表，由于运营须要，有些数据无法作数据脱敏，因此领导说，前端能不能作个水印，让数据安全一点：防止运营人员不按规范处理问题，私自截图。因此当我看到知乎那个提问是，我特别庆幸，没有让我作：限制用户截图。

从我我的经验来说，前端加水印有三个层次：

• 经过 CSS 背景加水印，简单粗暴，能骗一点文科运营。但稍微懂行的人，就知道经过 Elements 编辑面板屏蔽这个水印。正所谓你加的简单，别人去掉更简单。
• 经过 JS 定向植入水印dom节点，这个比上一个稍微复杂点，但仍是经过Elements 编辑面板屏蔽，只不过多思考一下，操做步骤多点。
• 终解: 服务端加水印生成列表图片，实现思路和图怪兽网站一致。但这个操做描述起来简单，具体实现就很是复杂，须要考虑投入产出比。

有可能你会疑问，为何是服务端加水印生成图片，而不是前端本身经过 canvas 生成？

• 第一，同上面提到过的，经过请求拿到敏感数据，自己就是不安全的；
• 第二，JS 自己是不安全的，可篡改；

JS 可篡改

我上面反复在说前端安全是个伪需求，你可能不信。但若是你知道 JS 是可篡改的，那你就明白为何了。咱们老是在提JS丑化，但丑化更可能是减小包的体积，在某种程度上，可让发布的js资源可读性更差，但作到不可读很难。

接下来体验一下什么叫 JS 可篡改吧

实战演练

• 第一步：Chrome 下载安装 Header Editor 插件

• 第二步：找一个目标网站，并找到一个你想篡改的 JS 资源。我这里以我经常使用的做图网站的jquery 资源（https://js.tuguaishou.com/js/...）引用为例；
• 第三步：拷贝代码带编辑器，输入你想篡改的内容，我这里就只加了个console输出, 而后本地起一个静态资源服务

// ...
  console.log('do some change, ho ho ho');
  var c = []
    , d = c.slice
    , e = c.concat
  // ...

• 第四步，使用插件重定向网站静态资源，我这里就是使用本地的jquery 代替网站原有的，保存配置并启动那个规则；

• 第五步: 强刷浏览器，使代理资源生效，当你看到请求被标成了307的响应，说明篡改生效，而后看console，就有了对应的输出；

至此，一次完整的篡改完成。但这个教程并非让你用这个方法去作一些XX的事情，而只是让你明白因为JS的可篡改，咱们在作网站设计时，你须要时刻思考代码安全的事，能作不表明能够作。

分享个趣事

年初，前公司要作一次大的系统融合：就是两个子公司各有各的权限系统，而后资本青睐的一方占优(以系统设计来说，咱们的权限系统设计更专业)，被遗弃的咱们不得不改咱们现有系统，去对接对方的系统。

这中间由于异地沟通问题，对方开始没把规则说好，而后对接人将咱们清洗重组后的数据导入了数据库。后面因为须要修改一些数据，网站页面提示咱们导入数据key的格式不对，而这个key，又被设置成了只读，这就走入了死路。而后沟通能不能把数据库数据删除了从新导入，对方一万个不情愿，让咱们本身在网站上本身删除再添加数据，那但是200多条数据啊，侮辱谁呢？？？？

这真的把我同事们惹毛了，而后就试了上面的招数，看了对方的JS，代理而后再一提交，成功！！！

知道对方业余，但没想到这么业余：仅在前端作了限制，服务端没校验。

这个案例提醒咱们，前端重在交互，服务端重在安全，JS是可篡改的；因此不要产品觉得，要你觉得，用你的专业Say no!!!；也告诉咱们作技术，谦虚点，能帮忙就尽可能帮，作个好人。

结语

又摧拉枯朽扯了一堆，希望对你之后的需求评审和方案设计有用。前端安全重要吗？重要。网站的安全全交给前端合适吗? 不合适。