硬编码/存储API密钥等凭证是否合规？是否会暴露数据库权限？

硬编码、未加密存储API Key、SK Key、API Token这类敏感凭证的做法，既不符合数据安全合规要求，也存在极高的安全风险，大概率会导致凭证泄露，进而可能引发数据库访问权限被非法获取。

各场景的具体风险与合规性分析 #

1. 硬编码在代码变量中 #

const String apiKey = "12345-ABCDE-SecretKey";

• 风险：编译后的应用包（APK/IPA等）可通过反编译工具轻松提取硬编码密钥，任何人拿到安装包就能获取敏感凭证。
• 合规性：违反数据安全合规标准（如GDPR、PCI DSS）中“敏感信息需加密存储、最小化暴露”的要求。

2. 未加密存入SharedPreferences #

SharedPreferences prefs = await SharedPreferences.getInstance();
prefs.setString('apiKey', '12345-abcde-67890');

• 风险：SharedPreferences默认以明文存储，设备root后可直接读取对应文件获取密钥；未root设备也可能被恶意应用通过漏洞窃取数据。
• 合规性：未对敏感凭证加密，不符合敏感数据存储的合规要求。

3. 测试日志保留在发布版本 #

debugPrint("API Key: 12345-abcde-67890");

• 风险：发布版本中保留这类日志，用户或攻击者可通过日志工具捕获密钥；应用崩溃时的日志也可能包含敏感内容。
• 合规性：属于敏感信息未妥善处理，违反数据安全保护要求。

4. 未加密存入环境变量/全局变量 #

export API_KEY="12345-abcde-67890"

• 风险：环境变量在进程内存中明文存储，攻击者可通过读取进程内存、获取环境变量列表等方式拿到密钥；全局变量同样存在内存泄露或被恶意读取的风险。
• 合规性：未对敏感凭证采取加密保护，不符合合规标准。

正确的处理方案 #

• 后端中转：敏感API请求通过自有后端服务中转，前端仅存储短期、低权限的Token，不直接持有核心密钥。
• 加密存储：必须存储凭证时，用AES等强加密算法加密后再存储，加密密钥从系统安全容器（如Android Keystore、iOS Keychain）获取。
• 日志清理：发布版本彻底移除所有含敏感信息的日志输出，仅在开发环境保留调试日志。
• 专业密钥管理：用密钥管理服务（如Android Keystore、AWS KMS）管理核心密钥，避免直接在代码或配置中暴露。

内容的提问来源于stack exchange，提问作者Sudip Mahanta