敏感数据处理

概述

2019年，某知名酒店集团遭遇数据泄露，超过5亿条宾客信息被暴露，其中包括姓名、邮箱、信用卡号等敏感数据。这类事件不仅导致巨额罚款，更严重损害了用户信任。前端应用处于数据处理链路的最前沿，每天都在与用户的个人信息、支付数据、认证凭证打交道。一个不经意间的console.log、一张未做脱敏的用户列表、一次不正确的密钥管理，都可能成为数据泄露的入口。

敏感数据处理不是可选的安全加固，而是前端工程师的基本职责。本节从实际案例出发，系统讲解前端场景中的敏感数据识别、安全传输与存储策略、脱敏展示技术、Web Crypto API的工程应用，以及GDPR等合规框架对前端的具体要求。

目标

• 建立敏感数据分级意识，掌握不同级别数据的差异化保护策略
• 精通环境变量与密钥管理的最佳实践，防止凭证泄露
• 掌握数据脱敏的工程方法，在数据展示与隐私保护间取得平衡
• 理解Web Crypto API的能力边界，能够设计端到端加密方案
• 了解GDPR、个人信息保护法等合规要求在前端的落地细节

知识体系

1. 敏感数据分类与风险矩阵

在实际工程项目中，并非所有数据都需要同等强度的保护。过度保护会浪费开发资源，保护不足则可能导致严重后果。建立科学的敏感数据分级制度，是安全架构的第一步。

Level 1 — 高度敏感（绝不应出现在前端） 这类数据一旦泄露会造成不可挽回的损失。数据库凭证、API密钥、服务端加密密钥属于系统级别的秘密，它们决定着整个应用的安全根基。用户密码原文更是用户的终极信任凭证——尽管现代系统不会存储明文，但密码本身永远不应该以任何形式出现在前端代码或日志中。支付卡CVV是PCI DSS（支付卡行业数据安全标准）明确禁止存储的数据，任何前端代码都不应该保留它。

Level 2 — 敏感（加密传输，最小化暴露） 这类数据在必要时可以在前端存在，但需要严格控制流转范围。用户密码在输入框中存在是不可避免的，但必须采用安全输入组件，并在提交后立即从内存中清除。支付卡号、身份证号、个人手机号和邮箱属于PII（个人身份信息），在展示时必须经过脱敏处理，在传输时必须使用HTTPS加密。Access Token和Session ID是用户的身份证明，必须通过HttpOnly Cookie或内存存储，绝不能写入localStorage。

Level 3 — 个人信息（需要保护但可展示） 用户姓名、地址、头像、购物记录等属于一般个人信息。这类数据在征得用户同意后可以收集和展示，但同样需要采取基本的安全措施：传输加密、访问控制、日志脱敏。

理解这个分级体系后，我们需要进一步思考：同一份数据在不同的上下文中可能具有不同的敏感度。例如，用户手机号在登录场景中是认证因素（Level 2），但在通讯录功能中可能只是普通联系信息（Level 3）。工程师需要根据具体场景做出判断，而非机械套用分级表。

2. 环境变量与密钥管理

前端代码最终会打包并部署到用户浏览器，这意味着代码中的任何字符串都可以被任何人查看。许多人习惯在代码中硬编码API密钥，认为这只是"内部"的东西，但一旦代码被部署，这个"内部"秘密就暴露给了全世界。

来看一个典型的错误配置。在Next.js项目中，如果你在.env文件中写入NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_xxxxx，这个前缀NEXT_PUBLIC_的含义是"允许在客户端代码中使用"。但Stripe的Secret Key本质上是服务端密钥，绝不应该暴露到客户端。正确的做法是：将公钥pk_live_xxxxx设置为NEXT_PUBLIC_STRIPE_PUBLIC_KEY，公钥可以安全地暴露给前端；而Secret Key sk_live_xxxxx只能存在于服务端环境变量中，通过API路由间接调用Stripe服务。

// ❌ 在前端代码中硬编码密钥
const API_KEY = 'sk_live_xxxxxxxxxxxxx';  // 会被打包到 bundle 中，任何人都能提取

// ❌ 使用 NEXT_PUBLIC_ 前缀暴露敏感密钥
// .env
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_xxxxx  // ❌ 暴露到客户端

// ✅ 只暴露公开的 Key
// .env
NEXT_PUBLIC_STRIPE_PUBLIC_KEY=pk_live_xxxxx  // ✅ 公钥可以暴露
STRIPE_SECRET_KEY=sk_live_xxxxx              // ✅ 仅服务端可访问

// ✅ 通过 API 代理隐藏密钥
// 前端 - 不需要知道任何 Stripe 密钥
const response = await fetch('/api/payment', {
  method: 'POST',
  body: JSON.stringify({ amount, currency }),
});

// 服务端 API 路由
export async function POST(request) {
  const { amount, currency } = await request.json();
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
  const intent = await stripe.paymentIntents.create({ amount, currency });
  return Response.json({ clientSecret: intent.client_secret });
}

密钥管理的另一个重要维度是git历史。即使你今天删除了包含密钥的文件，git历史仍然保留着它。安全审计工具如git-secrets、trufflehog、gitleaks可以扫描git历史和当前代码库中的敏感信息。建议在CI/CD流水线中集成这些工具，在代码合并前阻止敏感信息进入代码库。

# 使用 git-secrets 扫描当前提交
git secrets --scan

# 扫描整个 git 历史
git secrets --scan-history

# 使用 trufflehog 深度扫描
trufflehog git file://. --since-commit HEAD~50

# 使用 gitleaks 检测
gitleaks detect --source .

同时，.gitignore文件的配置也至关重要。确保.env、.env.local、.env.production、所有*.pem和*.key文件、credentials.json、serviceAccountKey.json都被排除在版本控制之外。IDE配置文件如.vscode/settings.json有时也会包含敏感路径或API配置，同样需要谨慎处理。

3. 数据脱敏展示

数据脱敏是在数据可用性与隐私保护之间寻求平衡的技术。在很多业务场景中，我们需要在界面上展示用户信息，但不应该完整暴露。例如，客服人员需要看到用户的手机号来核实身份，但不需要看到完整的号码——显示为138****5678既满足了业务需求，又保护了用户隐私。

脱敏策略需要根据数据类型定制，不能用同一套规则处理所有数据。手机号的脱敏逻辑是保留前三位和后四位，中间用星号替代；邮箱则需要保留域名和首尾字符，例如u***[email protected]；身份证号涉及更敏感的信息，通常保留前三位和后四位；银行卡号最为敏感，一般只显示后四位。

// 敏感数据脱敏工具
const Masker = {
  // 手机号：138****5678
  phone(phone: string): string {
    if (!phone || phone.length < 7) return '***';
    return phone.slice(0, 3) + '****' + phone.slice(-4);
  },

  // 邮箱：u***[email protected]
  email(email: string): string {
    const [local, domain] = email.split('@');
    if (!domain) return '***';
    const masked = local[0] + '***' + (local.length > 1 ? local.slice(-1) : '');
    return `${masked}@${domain}`;
  },

  // 身份证：110***********1234
  idCard(id: string): string {
    if (!id || id.length < 8) return '***';
    return id.slice(0, 3) + '*'.repeat(id.length - 7) + id.slice(-4);
  },

  // 银行卡：**** **** **** 1234
  bankCard(card: string): string {
    const clean = card.replace(/\s/g, '');
    if (clean.length < 4) return '***';
    return '**** **** **** ' + clean.slice(-4);
  },

  // 姓名：张**
  name(name: string): string {
    if (!name) return '***';
    if (name.length <= 1) return name + '**';
    return name[0] + '*'.repeat(name.length - 1);
  },
};

在React组件中应用脱敏时，通常会提供切换开关，让用户在需要时查看完整数据。这个功能看似简单，但涉及安全性与用户体验的权衡：切换按钮本身可能成为社交工程攻击的入口——攻击者伪装成客服人员，通过"帮你查看完整信息"的话术诱导用户点击。因此，一些高安全要求的场景会限制敏感数据的查看权限，或者要求二次认证后才显示完整数据。

function SensitiveText({
  value,
  type,
  showToggle = false,
}: {
  value: string;
  type: 'phone' | 'email' | 'idCard' | 'bankCard' | 'name';
  showToggle?: boolean;
}) {
  const [visible, setVisible] = useState(false);
  const masked = Masker[type](value);

  return (
    <span>
      {visible ? value : masked}
      {showToggle && (
        <button
          onClick={() => setVisible(!visible)}
          aria-label={visible ? '隐藏' : '显示'}
        >
          {visible ? '🙈' : '👁️'}
        </button>
      )}
    </span>
  );
}

4. Web Crypto API

浏览器原生提供了Web Crypto API，这是进行客户端加密的安全选择。与自行实现的加密逻辑不同，Web Crypto API的算法实现经过严格的安全审计，密钥生成使用加密安全的随机数源，不会因JavaScript的弱类型产生边界漏洞。

Web Crypto API的核心是SubtleCrypto接口，支持AES-GCM、RSA-OAEP、SHA-256等标准算法。AES-GCM是对称加密算法，适合加密大量数据；RSA-OAEP是非对称加密算法，适合加密小数据块或密钥交换。两者的组合使用可以构建安全的端到端加密方案。

// Web Crypto API 提供浏览器原生的加密能力

// 生成密钥
async function generateKey() {
  return crypto.subtle.generateKey(
    { name: 'AES-GCM', length: 256 },
    true,     // extractable
    ['encrypt', 'decrypt']
  );
}

// 加密数据
async function encrypt(key, data) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const encoded = new TextEncoder().encode(data);

  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    key,
    encoded
  );

  // 返回 IV + 密文
  return {
    iv: Array.from(iv),
    data: Array.from(new Uint8Array(ciphertext)),
  };
}

// 解密数据
async function decrypt(key, encrypted) {
  const iv = new Uint8Array(encrypted.iv);
  const data = new Uint8Array(encrypted.data);

  const decrypted = await crypto.subtle.decrypt(
    { name: 'AES-GCM', iv },
    key,
    data
  );

  return new TextDecoder().decode(decrypted);
}

需要特别强调的是，客户端加密不能替代服务端加密。前端加密可以保护数据在传输和存储过程中的机密性，防止中间人攻击和本地数据泄露；但如果服务端本身就是威胁方，或者攻击者通过XSS获取了页面控制权，客户端加密就失去了意义。因此，Web Crypto API更适合用于端到端加密场景——例如加密本地笔记、保护端到端通讯——而不是作为"前端不需要服务端安全"的借口。

一个常见的工程实践是使用Web Crypto API进行密码预处理。用户输入密码后，前端先对其进行加盐Hash，再发送到服务端。这个过程不是为了替代服务端的密码验证，而是为了防止用户在不同网站使用相同密码时，一次泄露导致所有账户被破解。前端Hash后的密码对于攻击者来说是新的"密码"，即使他们获取了数据库，也无法直接用于登录其他网站。

// 密码 Hash（用于客户端预处理，不能替代服务端 Hash）
async function hashPassword(password, salt) {
  const encoded = new TextEncoder().encode(password + salt);
  const hashBuffer = await crypto.subtle.digest('SHA-256', encoded);
  return Array.from(new Uint8Array(hashBuffer))
    .map((b) => b.toString(16).padStart(2, '0'))
    .join('');
}

端到端加密的工程实现需要仔细设计。一个完善的E2EE消息系统需要处理密钥交换、消息加密、离线消息解密、设备更换等复杂场景。核心思想是使用混合加密：用AES加密实际消息内容，用RSA加密AES的临时密钥。这样既保证了加密速度（AES对称加密快），又保证了密钥交换的安全性（RSA非对称加密）。

// E2E 加密消息示例
class E2EEncryption {
  // 生成密钥对
  static async generateKeyPair() {
    return crypto.subtle.generateKey(
      {
        name: 'RSA-OAEP',
        modulusLength: 2048,
        publicExponent: new Uint8Array([1, 0, 1]),
        hash: 'SHA-256',
      },
      true,
      ['encrypt', 'decrypt']
    );
  }

  // 导出公钥
  static async exportPublicKey(keyPair) {
    const exported = await crypto.subtle.exportKey('spki', keyPair.publicKey);
    return btoa(String.fromCharCode(...new Uint8Array(exported)));
  }

  // 混合加密：用 AES 加密数据，用 RSA 加密 AES 密钥
  static async encryptMessage(publicKey, message) {
    // 生成临时 AES 密钥
    const aesKey = await crypto.subtle.generateKey(
      { name: 'AES-GCM', length: 256 },
      true,
      ['encrypt']
    );

    // AES 加密消息
    const iv = crypto.getRandomValues(new Uint8Array(12));
    const encodedMessage = new TextEncoder().encode(message);
    const encryptedMessage = await crypto.subtle.encrypt(
      { name: 'AES-GCM', iv },
      aesKey,
      encodedMessage
    );

    // RSA 加密 AES 密钥
    const rawAesKey = await crypto.subtle.exportKey('raw', aesKey);
    const encryptedKey = await crypto.subtle.encrypt(
      { name: 'RSA-OAEP' },
      publicKey,
      rawAesKey
    );

    return { encryptedMessage, encryptedKey, iv };
  }
}

5. 表单敏感数据处理

表单是前端处理敏感数据最常见的场景。密码、信用卡号、身份证号等都需要通过表单输入。正确配置表单字段不仅能提升安全性，还能改善用户体验。

密码字段应该使用type="password"，并设置autocomplete="current-password"让浏览器知道这是登录密码，可以调用密码管理器。同时应该关闭浏览器的自动填充、拼写检查和首字母大写功能，防止密码被意外泄露或被浏览器、插件读取。

<!-- 密码字段安全属性 -->
<input
  type="password"
  name="password"
  autocomplete="current-password"
  spellcheck="false"
  autocorrect="off"
  autocapitalize="off"
/>

<!-- 信用卡字段 -->
<input
  type="text"
  name="cc-number"
  inputmode="numeric"
  autocomplete="cc-number"
  pattern="[0-9\s]+"
  maxlength="19"
/>

信用卡字段的处理尤其复杂。PCI DSS要求CVV绝不能被存储，而卡号在存储前需要加密。但在前端展示和表单处理时，也有安全要求：提交后立即清除表单中的敏感字段，防止浏览器缓存或历史记录泄露；在页面上内存中的卡号应该尽快使用，使用完毕后主动清空。

// 表单提交后清除敏感数据
function handlePaymentSubmit(event) {
  event.preventDefault();
  const form = event.target;
  const formData = new FormData(form);

  // 提交数据
  submitPayment(Object.fromEntries(formData));

  // ✅ 提交后清除表单中的敏感字段
  form.querySelector('[name="cc-number"]').value = '';
  form.querySelector('[name="cc-cvv"]').value = '';
  form.querySelector('[name="cc-exp"]').value = '';
}

// 防止敏感数据被浏览器缓存
// ✅ 禁止缓存包含敏感数据的页面
app.get('/account/payment', (req, res) => {
  res.set({
    'Cache-Control': 'no-store, no-cache, must-revalidate, private',
    'Pragma': 'no-cache',
    'Expires': '0',
  });
  // 渲染页面
});

6. 日志与调试安全

开发过程中，console.log是我们调试代码的主要工具。但生产环境中，不加选择地输出日志可能成为敏感数据泄露的渠道。一次console.log('User login:', { email, password })就会将用户密码暴露在浏览器控制台中，如果用户截图分享，或者攻击者通过XSS注入读取控制台输出，后果不堪设想。

建立安全的日志习惯需要从架构层面入手。生产环境的日志应该发送到专门的日志服务（如Sentry、Datadog），而不是输出到控制台。日志服务可以集中管理访问权限、设置数据保留策略、并对敏感字段进行自动过滤。在代码层面，应该封装统一的日志工具，明确标记哪些字段是敏感的。

// ❌ 在日志中输出敏感数据
console.log('User login:', { email, password });
console.log('Payment:', { cardNumber, cvv });
console.log('Token:', accessToken);

// ✅ 安全的日志工具
class SafeLogger {
  private sensitiveFields = new Set([
    'password', 'token', 'secret', 'key', 'authorization',
    'cookie', 'cardNumber', 'cvv', 'ssn', 'creditCard',
  ]);

  log(message: string, data?: Record<string, unknown>) {
    if (process.env.NODE_ENV === 'production') {
      // 生产环境：发送到日志服务，不输出到控制台
      this.sendToService(message, this.redact(data));
      return;
    }
    console.log(message, data ? this.redact(data) : '');
  }

  private redact(data?: Record<string, unknown>): Record<string, unknown> {
    if (!data) return {};
    const redacted: Record<string, unknown> = {};
    for (const [key, value] of Object.entries(data)) {
      if (this.sensitiveFields.has(key.toLowerCase())) {
        redacted[key] = '[REDACTED]';
      } else if (typeof value === 'object' && value !== null) {
        redacted[key] = this.redact(value as Record<string, unknown>);
      } else {
        redacted[key] = value;
      }
    }
    return redacted;
  }

  private sendToService(message: string, data: Record<string, unknown>) {
    navigator.sendBeacon('/api/logs', JSON.stringify({ message, data }));
  }
}

const logger = new SafeLogger();

使用navigator.sendBeacon而非fetch发送日志是更好的选择。sendBeacon设计用于在页面卸载时发送数据，确保即使用户关闭标签页或跳转离开，日志也能被发送。而普通的fetch请求在页面卸载时可能被浏览器取消。

7. 剪贴板安全

复制粘贴是用户日常操作的高频场景，也是敏感数据流转的潜在风险点。用户在复制银行卡号后，如果粘贴到了错误的地方，可能导致信息泄露。更隐蔽的攻击是恶意网页通过剪贴板API读取用户复制的内容——例如用户刚刚复制了密码，下一个访问的网页就悄悄读取并发送出去。

现代浏览器已经对剪贴板访问进行了权限限制，网页需要用户授权才能读取剪贴板内容。但写入剪贴板是另一回事——恶意网页可以毫无限制地向剪贴板写入数据，可能导致用户的复制内容被覆盖，或者写入的内容看起来与用户复制的不同（视觉欺骗）。

// 限制敏感数据的复制
function preventCopy(element) {
  element.addEventListener('copy', (event) => {
    event.preventDefault();
    event.clipboardData?.setData('text/plain', '');
  });

  // 也可以通过 CSS
  // user-select: none;
}

// 安全地写入剪贴板
async function secureCopy(text) {
  try {
    await navigator.clipboard.writeText(text);
    // 一段时间后自动清除剪贴板
    setTimeout(async () => {
      try {
        await navigator.clipboard.writeText('');
      } catch {
        // 页面可能已失焦
      }
    }, 30000); // 30 秒后清除
  } catch (error) {
    console.error('Failed to copy');
  }
}

自动清除剪贴板是一种纵深防御策略。即使攻击者获取了剪贴板内容，敏感信息也会在30秒后消失。这个时间窗口足够用户完成任务，又不至于给攻击者太多机会。当然，30秒是经验值，实际场景中可以根据敏感程度调整。

8. 合规要求

GDPR（通用数据保护条例）和中国的个人信息保护法不仅约束服务端和数据库，前端代码同样在监管范围内。理解这些法规对前端的具体要求，是构建合法产品的必要条件。

数据最小化原则要求只收集业务必需的用户数据。在表单设计中，每个字段都应该是必要的或明确标记为可选的。如果某个字段与核心功能无关，就不应该收集。这不仅是法律要求，也是保护用户隐私的基本伦理。一些公司会过度收集用户信息以备"将来可能用"，这种做法在GDPR下是违规的。

用户同意是数据收集的合法性基础。对于Cookie和追踪脚本，必须在收集前获得用户明确同意。这意味着不能使用"一旦使用网站即表示同意"的霸王条款，而应该提供清晰的选择界面，让用户真正理解他们在同意什么。Cookie同意横幅应该说明数据将如何被使用，用户应该能够轻松拒绝非必要的数据收集。

用户权利包括查看个人数据、修改个人数据、删除个人数据和数据可携带性。从前端角度看，这意味着应用需要提供数据导出功能（通常是多数据格式下载）、个人资料编辑页面、账号注销功能，以及将用户数据导出为通用格式的能力。这些功能的设计需要考虑用户体验——过于复杂的注销流程本身可能也是一种违规（被称为"黑暗模式"，dark pattern）。

数据保护的技术措施包括传输加密（使用HTTPS）、敏感数据脱敏展示、日志中不包含个人数据、对第三方脚本进行合规评估。引入第三方脚本（如分析工具、广告SDK）时，需要确保这些脚本也符合数据保护要求。第三方脚本是GDPR合规的薄弱环节，很多数据泄露事件都是通过第三方脚本发生的。

// Cookie 同意管理
interface ConsentPreferences {
  necessary: true;        // 始终为 true
  analytics: boolean;
  marketing: boolean;
  preferences: boolean;
}

function CookieConsent() {
  const [consent, setConsent] = useState<ConsentPreferences | null>(null);

  function handleAcceptAll() {
    const preferences: ConsentPreferences = {
      necessary: true,
      analytics: true,
      marketing: true,
      preferences: true,
    };
    saveConsent(preferences);
    applyConsent(preferences);
  }

  function handleRejectAll() {
    const preferences: ConsentPreferences = {
      necessary: true,
      analytics: false,
      marketing: false,
      preferences: false,
    };
    saveConsent(preferences);
    applyConsent(preferences);
  }

  function applyConsent(preferences: ConsentPreferences) {
    if (preferences.analytics) {
      loadAnalytics();
    }
    if (preferences.marketing) {
      loadMarketingScripts();
    }
  }

  if (consent) return null;

  return (
    <div role="dialog" aria-label="Cookie 设置">
      <p>我们使用 Cookie 来改善您的体验。</p>
      <button onClick={handleAcceptAll}>全部接受</button>
      <button onClick={handleRejectAll}>仅必要</button>
      <button onClick={() => setShowDetails(true)}>自定义</button>
    </div>
  );
}

实战练习

练习 1：数据脱敏系统

实现一套完整的数据脱敏组件库，支持手机号、邮箱、身份证、银行卡等类型。要求支持多种脱敏规则配置、脱敏后的数据格式校验、以及便捷的React组件集成。

练习 2：端到端加密聊天

使用Web Crypto API实现一个简单的端到端加密消息系统。实现密钥对生成、公钥交换、消息加解密、消息发送和接收的完整流程。思考如何处理消息历史、离线消息、以及设备更换场景。

练习 3：GDPR 合规改造

为现有项目添加Cookie同意管理和数据导出/删除功能。设计一个符合GDPR要求的同意界面，实现同意偏好的持久化存储，并在用户注销时彻底删除个人数据。

延展阅读

• Web Crypto API - MDN：浏览器原生加密API的完整文档，包含各算法的使用指南和安全性注意事项。
• OWASP Sensitive Data Exposure：OWASP对敏感数据泄露风险的权威解读和防御指南。
• GDPR for Developers - Smashing Magazine：面向开发者的GDPR实用指南，详细解释了各项要求的技术含义。
• git-secrets - GitHub：AWS实验室开发的git敏感信息扫描工具，可以阻止包含密钥的代码进入版本控制。

关键术语