我创建了一个Restful API，一个网站（ReactJS / Ruby on Rails）和一个移动应用程序（React Native）。
我正在使用API在网站和移动应用上显示和处理数据。
在网站上，我使用的jQuery AJAX请求看起来像这样：
...some other code
componentDidMount () {
$.getJSON('https://example.com/api/v1/accounts?key=MASTER-API-KEY', (data) => {
this.setState({
accounts: data.accounts
});
});
}
...some other code
在移动应用程序中，我使用fetch，看起来像这样：
...some other code
fetch('https://example.com/api/v1/accounts?key=MASTER-API-KEY', {
method: 'GET',
...some other code
用户还拥有自己的API密钥，这些密钥具有基于用户级别的有限权限。
如果只有他们发送了有效的API密钥，我已经有了处理请求的验证。但是在网站和应用程序上，我使用的是一个可以访问所有人的主API密钥。
我相信这可以在网站上的源文件中看到，它可以在移动应用程序中进行逆向工程。
我对网站的可能解决方案是在服务器中制作流程而不是使用AJAX，但是如何在我的ReactJS组件上访问它？
对于移动应用程序，我应该切换到使用Swift / Java并在那里发出请求而不是获取吗？
我想首先明确WHAT和WHO之间的区别是访问API服务器。
WHO是移动应用程序的用户，您可以通过多种方式进行身份验证，授权和识别，例如使用OpenID或OAUTH2流程。
现在你需要一种方法来识别什么是调用你的API服务器，这里的事情变得比大多数开发人员想象的更棘手。什么是向API服务器发出请求的东西，它真的是你真正的移动应用程序，还是机器人，自动脚本或攻击者使用像Postman这样的工具手动戳你的API服务器？
那么要确定开发人员倾向于使用API密钥，他们通常会在移动应用程序的代码中进行硬编码，有些人会在移动应用程序的运行时更加努力地计算它，从而成为一个动态秘密。反对前一种方法，即嵌入代码中的静态秘密。
如果只有他们发送了有效的API密钥，我已经有了处理请求的验证。但是在网站和应用程序上，我使用的是一个可以访问所有人的主API密钥。我相信这可以在网站上的源文件中看到，它可以在移动应用程序中进行逆向工程。
在Web应用程序中，我们只需要使用浏览器开发工具检查源代码，或者右键单击视图页面源并搜索API密钥。
在移动应用程序上，我们可以首先使用linux上的string命令快速监视二进制文件：
$ strings -aw app-debug.apk | grep -C 1 '_API_' -
ic_launcher_round
GRADLE_API_KEY
GRADLE_ENV_API_KEY
abc_action_bar_home_description
为了更完整和详细扫描，MobSF将帮助您对移动应用程序二进制文件进行反向工程，以便提取API密钥并枚举其他攻击向量。
移动安全框架是一种自动化的一体化移动应用程序（Android / iOS / Windows）笔测试框架，能够执行静态分析，动态分析，恶意软件分析和Web API测试。
因此，在客户端运行并需要一些秘密来访问API的任何内容都可能以不同方式被滥用，您可以在this series上了解有关Mobile API安全技术的文章。本文将教您如何使用API密钥，用户访问令牌，HMAC和TLS固定来保护API以及如何绕过它们。
但是如何在我的ReactJS组件上访问它？
抱歉，但我没有相关知识可以帮助您，但请继续阅读以了解如何保护您的API服务器。
我对网站的可能解决方案是在服务器中制作进程而不是使用AJAX ...？
对于移动应用程序，我应该切换到使用Swift / Java并在那里发出请求而不是获取吗？
移动应用程序或Web应用程序应仅与您控制的API服务器通信，并且任何对第三方API服务的访问必须由您控制的同一API服务器完成。
通过这种方式，您可以将攻击面限制在一个地方，在那里您将使用尽可能多的防御层，因为您保护的是值得的。
对于服务于Web应用程序的API，您可以使用多个密集层，从reCaptcha V3开始，然后是Web Application Firewall（WAF），最后如果您能够负担得起User Behavior Analytics（UBA）解决方案。
谷歌reCAPTCHA V3：
reCAPTCHA是一项免费服务，可以保护您的网站免受垃圾邮件和滥用。 reCAPTCHA使用先进的风险分析引擎和自适应挑战，以防止自动化软件在您的网站上进行滥用活动。这样做可以让您的有效用户轻松通过。
...帮助您在没有任何用户摩擦的情况下检测网站上的滥用流量。它会根据与您网站的互动返回分数，并为您提供更大的灵活性来采取适当的措施。
WAF - Web Application Firewall：
Web应用程序防火墙（或WAF）过滤，监视和阻止与Web应用程序之间的HTTP流量。 WAF与常规防火墙的区别在于，WAF能够过滤特定Web应用程序的内容，而常规防火墙则充当服务器之间的安全门。通过检查HTTP流量，它可以防止源自Web应用程序安全漏洞的攻击，例如SQL注入，跨站点脚本（XSS），文件包含和安全性错误配置。
UBA - User Behavior Analytics：
Gartner定义的用户行为分析（UBA）是一个关于检测内部威胁，针对性攻击和财务欺诈的网络安全流程。 UBA解决方案着眼于人类行为的模式，然后应用算法和统计分析来检测那些模式中的有意义的异常 - 指示潜在威胁的异常。 UBA不是跟踪设备或安全事件，而是跟踪系统的用户。像Apache Hadoop这样的大数据平台正在增加UBA功能，允许他们分析数PB的数据来检测内部威胁和高级持续性威胁。
所有这些解决方案都基于否定识别模型工作，换句话说，他们尽力识别坏东西，而不是好东西，从而尽管使用了先进的技术，但它们容易出现误报其中一些，如机器学习和人工智能。
因此，您可能会发现自己不得不放松阻止访问API服务器的方式，以免影响好用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时他们正确地阻止未经授权的用户。
关于为移动应用程序提供服务的API，可以使用移动应用程序证明解决方案来使用正面识别模型，该解决方案向API服务器保证可以信任请求而不会出现误报。
移动应用证明服务的作用是在运行时保证您的移动应用未被篡改或未在根设备中运行，方法是在后台运行SDK，该SDK将与云中运行的服务进行通信以证明正在运行移动应用和设备的完整性。
在成功证明移动应用程序完整性时，会发布短时间JWT令牌，并使用只有API服务器和云中的移动App证明服务才知道的秘密签名。在移动应用证明失败的情况下，JWT令牌使用API服务器不知道的秘密进行签名。
现在，应用程序必须在每次API调用时发送请求标头中的JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时提供请求，并在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用证明服务使用的秘密，即使应用程序被篡改，在有根设备中运行或通过正在进行的连接进行通信，也无法在运行时对其进行反向工程。中间人攻击的目标。
移动应用证明服务已作为SAAS解决方案存在于Approov（我在这里工作），该解决方案为多个平台提供SDK，包括iOS，Android，React Native等。集成还需要对API服务器代码进行少量检查，以验证云服务发出的JWT令牌。此检查对于API服务器能够决定要提供哪些请求以及拒绝哪些请求是必要的。
最后，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的GDPR法规）选择用于保护API服务器的解决方案。
所以使用API键可能听起来像锁住你家的门并把钥匙留在垫子下面，但不使用它们喜欢让你的车停在车门关闭的地方，但钥匙在点火时。
在React中，我创建一个.env文件并将其配置添加到其中。
.env文件：
REACT_APP_SPOTIFY_REDIRECT_URI="xxxxxx"
REACT_APP_SPOTIFY_PUBLIC_CLIENT_ID="xxxxxxx"
如果我想通过以下行使用这些参数：
const consumer_public_key = process.env.REACT_APP_SPOTIFY_PUBLIC_CLIENT_ID;
我不确定这一点但你需要写REACT_APP_到你的参数的前缀，以便成功调用。
如果你在节点上开发（我想你是），这应该工作：