前端敏感信息隐藏的实践与防踩坑指南

为什么我要对比这几个方案？

最近在做一个项目，涉及到用户敏感信息的隐藏和保护。比如用户的身份证号、手机号这些数据，在界面上需要部分隐藏。这种需求其实很常见，但具体实现方式却有不少坑。我试了几种常见的技术方案，最后总结了一下各自的优缺点，想分享给大家。

说白了，我的目标很简单：既要保证敏感信息不被直接暴露，又不能影响用户体验，还得方便开发和维护。废话不多说，直接进入正题。

谁更灵活？谁更省事？

先说结论：我比较喜欢用前端正则处理的方式，虽然它不是最安全的，但在大多数场景下足够用了，而且代码简单好维护。如果你追求更高的安全性，可以考虑后端返回脱敏数据的方案，但这会增加前后端沟通成本。

下面详细聊聊几种方案：

• 前端正则替换
• 后端返回脱敏数据
• 加密解密方案

前端正则替换：简单粗暴，亲测有效

这个方案的核心思想是，通过正则表达式在前端对敏感信息进行替换。比如把手机号中间四位换成星号（*）。代码如下：

function maskPhoneNumber(phone) {
  return phone.replace(/(d{3})d{4}(d{4})/, "$1****$2");
}

const phoneNumber = "13812345678";
console.log(maskPhoneNumber(phoneNumber)); // 输出：138****5678

这段代码非常简单，正则匹配手机号的前三位和后四位，然后把中间四位替换成星号。类似的逻辑也可以用在身份证号、银行卡号等其他敏感信息上。

优点很明显：实现起来快，改动成本低。如果需求变化了，比如要隐藏更多位数，改个正则就行。而且所有逻辑都在前端完成，后端不用操心。

缺点呢？最大的问题就是安全性不够高。因为原始数据还是传到了前端，虽然界面显示的是脱敏后的信息，但懂点技术的人打开浏览器调试工具，就能看到完整的未脱敏数据。所以这种方案适合那些对安全性要求不高的场景。

踩坑提醒：别忘了测试各种边界情况，比如空字符串、非数字字符、超长或超短的号码等。我之前就遇到过一个手机号字段为空的情况，结果页面上直接显示了一个乱七八糟的星号串，尴尬得很。

后端返回脱敏数据：更安全，但麻烦点

第二种方案是让后端直接返回脱敏后的数据。这样前端拿到的就是已经处理好的数据，完全不需要自己再做任何操作。举个例子：

{
  "phoneNumber": "138****5678"
}

后端可能用类似这样的逻辑：

def mask_phone_number(phone):
    if len(phone) == 11:
        return phone[:3] + "****" + phone[-4:]
    return phone

# 示例调用
masked_phone = mask_phone_number("13812345678")
print(masked_phone)  # 输出：138****5678

这种方式的优点是安全性更高，因为原始数据根本不会传到前端。即使有人打开了调试工具，也只能看到脱敏后的数据。

不过缺点也很明显：增加了前后端的沟通成本。每次有新的字段需要脱敏，都得跟后端同学对接一次。而且后端的逻辑也变复杂了，尤其是当字段很多的时候，代码会显得很冗长。

还有一点需要注意：如果你的后端接口已经被多个地方复用，贸然修改返回值可能会导致其他模块出问题。所以这种方案更适合新项目，或者那些对接口改动影响范围可控的场景。

加密解密方案：看着高大上，实际有点鸡肋

最后一个方案是用加密算法对敏感信息进行加密，前端拿到后再解密并显示脱敏内容。听起来很高大上，但实际上我觉得这玩意有点鸡肋。

比如可以用AES加密：

// 加密示例（Node.js环境）
const crypto = require('crypto');

function encrypt(text, key) {
  const cipher = crypto.createCipher('aes-256-cbc', key);
  let encrypted = cipher.update(text, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  return encrypted;
}

const originalData = "13812345678";
const key = "my-secret-key-123"; // 密钥
const encryptedData = encrypt(originalData, key);
console.log(encryptedData); // 输出加密后的字符串

前端拿到加密数据后，还需要再解密并脱敏显示。整个流程看起来挺复杂的，对吧？确实如此。

优点是：安全性最高，原始数据全程加密，即使被抓包也看不到真实内容。

缺点是：太麻烦了。前后端都需要引入额外的加密库，性能开销也不小。而且一旦密钥泄露，整个系统就会变得不安全。所以除非你是在做银行级别的应用，否则真的没必要这么折腾。

这里注意，我踩过好几次坑的地方是：密钥管理是个大问题。如果密钥硬编码在前端代码里，那基本等于裸奔。正确的做法是把密钥放在后端，前端通过接口获取临时密钥，但这又增加了复杂性。

我的选型逻辑

综合来看，我一般会选择前端正则替换的方案，因为它够简单、够灵活，能满足大部分需求。如果项目对安全性要求特别高，我会倾向于让后端返回脱敏数据。至于加密解密方案，我只会在极少数情况下考虑。

当然，具体选型还是要看场景。比如在一个内部管理系统中，安全性可能不是首要考虑因素，前端正则就够了；但如果是一个面向公众的电商平台，涉及用户隐私的数据最好还是让后端处理。

以上是我的对比总结，有不同看法欢迎评论区交流

这篇文章主要讲了三种敏感信息隐藏的技术方案，从代码到踩坑经验都分享了一下。总的来说，每种方案都有自己的适用场景，没有绝对的好坏之分。希望我的经验能对你有所帮助，如果你有更好的实现方式，欢迎在评论区留言讨论。