即使没有创建 API 服务的移动应用程序，也可以在网络上使用 API 服务。黑客可以通过窃听无线网络或执行中间人攻击来检测 API 调用、修改它们并直接攻击 API。
建议。移动应用程序的服务器端必须使用安全编码和配置实践。特别是，API 必须可靠地验证调用者的身份和权限。
2. 不受保护的数据存储
开发团队假设用户或恶意代码不会访问存储机密信息的移动设备文件系统。
建議。如果可能，请不要在设备上或其软件源 巴西电报数据 代码中存储敏感数据。如果您的业务需要在移动设备上存储敏感信息，请更多地使用加密，而不是仅仅依赖移动操作系统的加密功能。
3. 运输层面保护不足
人们普遍误以为使用 SSL/TLS 协议就能保证移动应用程序的安全。
建议。在客户端上使用证书或公钥固定（HPKP）来防止中间人攻击，或进行相互认证，以便服务器和客户端都经过认证并且不能否认他们的身份。确保使用最先进的配置（即今天的 TLS 1.2）对与服务器的所有连接进行加密（如果可能）。不要信任自定义证书，并确保您的 SSL 证书是最新的并由受信任的证书颁发机构签名。
4. 意外数据泄露
当关注数据保护时，人们通常从移动应用程序的典型用例开始，并尝试保护与其相关的数据。但事实是，在许多其他情况下，您的数据也会被查看、复制、缓存、记录、截屏和备份。
建议。请注意，为相应移动设备设计的操作系统通常允许用户复制和粘贴数据、截屏、备份数据、连接任何键盘以及使用第三方应用程序执行分析。考虑与此类场景相关的风险，并决定您的移动应用程序是否接受它。如果没有，您必须明确禁止此类移动应用程序操作或使用移动设备管理 (MDM) 或移动应用程序管理 (MAM) 解决方案控制设备。
5. 身份验证和授权机制薄弱
即使移动应用程序用户已经通过一次身份验证，他们的凭证也可能很容易通过不安全的无线网络被窃取。永远不要假设经过身份验证的用户自动拥有随时随地做任何他们想做的事情的权利。
建议。定期对用户进行身份验证并重新进行身份验证，然后再执行任何有风险的操作。每次都授权每个请求。
6. 破解密码
移动应用程序可能包含或使用本质上较弱的加密/解密算法，由于开发人员实现的架构中存在根本缺陷或密钥管理流程不佳，该算法可能被敌对势力直接破解。