引子
最近逼乎有一个很炽热的问题，叫前端是否限度用户截图？
当我看到这个问题，我就感觉这个提问者应该是个萌新，或者曾经被产品经理或 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!!!；也通知咱们做技术，虚心点，能帮忙就尽量帮，做个坏蛋。
结语
又摧拉枯朽扯了一堆，但愿对你当前的需要评审和方案设计有用。前端平安重要吗？重要。网站的平安全交给前端适合吗? 不适合。