如何保护主 API 密钥？
How to protect master API key?
我创建了一个 Restful API、一个网站（Rails 上的 ReactJS/Ruby）和一个移动应用程序（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 并在那里发出请求而不是获取？
如果你在节点上开发（我猜你是），这应该有效：
在 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_ 写入参数的前缀，以便在 React 中成功调用。
谁和什么正在访问 API 服务器
首先我想弄清楚 WHAT 和 WHO 正在访问 API 服务器之间的区别。
WHO 是移动应用程序的用户，您可以通过多种方式对其进行身份验证、授权和识别，例如使用 OpenID 或 OAUTH2 流程。
现在您需要一种方法来识别什么 正在调用您的API 服务器，这里的事情变得比大多数开发人员想象的更棘手。 WHAT 是向 API 服务器发出请求的东西，它真的是您的正版移动应用程序，还是机器人、自动脚本或攻击者手动浏览您的 API 服务器有像 Postman 这样的工具？
确定 什么 开发人员倾向于求助于 API 键，通常他们 hard-code 在他们的移动应用程序代码中，有些去额外的一英里并在移动应用程序中计算run-time，因此成为一个动态秘密，而不是以前的方法，即嵌入代码中的静态秘密。
API 键的问题
I already have the validation to process the request if only they have sent a valid API key. But on the website and the app, I am using a master API key that has access to all.
I believe that this can be seen in the source file on the website and it can be reverse engineered in the mobile app.
在网络应用程序中，我们只需要使用浏览器开发工具检查源代码，或者右键单击查看页面源代码并搜索 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 密钥并枚举其他攻击向量。
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
因此，任何在客户端运行并需要一些秘密才能访问 API 的东西都可能以不同的方式被滥用，您可以在 this series 篇关于移动 API 的文章中了解更多信息] 安全技术。本文将教您如何使用 API 密钥、用户访问令牌、HMAC 和 TLS 固定来保护 API 以及如何绕过它们。
保卫 API 服务器
but how can I access it on my ReactJS components?
抱歉，我没有足够的知识来帮助您，但请继续阅读以了解可以采取哪些措施来保护您的 API 服务器。
The possible solution that I have for the website is to make the process in the server instead of using AJAX...?
For the mobile app, should I switch to using Swift/Java and make the request there instead of fetch?
移动应用程序或 Web 应用程序应仅与您控制的 API 服务器通信，对第三方 API 服务的任何访问都必须由同一 [=104] =] 你控制的服务器。
通过这种方式，您可以将攻击面限制在一个地方，在那里您可以根据所保护的内容采用尽可能多的防御层。
对于 API 服务网络应用程序，您可以使用多层密集，从 reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) 解决方案开始。
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
所有这些解决方案都基于负面识别模型，换句话说，它们通过识别什么是坏的而不是什么是好的来尽力区分好坏，因此它们很容易出现误报，尽管他们中的一些人使用的先进技术，如机器学习和人工智能。
因此，您可能会经常发现自己不得不放松阻止对 API 服务器的访问，以免影响好的用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们会适当地阻止未经授权的用户。
关于 API 为移动应用程序提供服务的肯定识别模型可以通过使用移动应用程序证明解决方案来使用，该解决方案向 API 服务器保证请求可以被信任而没有虚假的可能性正面。
移动应用认证
移动应用证明服务的作用是在 run-time 保证您的移动应用未被篡改或未被 运行 在已获得 root 权限的设备中被 运行 中的 SDK将与云中的服务 运行 通信以证明移动应用程序和设备的完整性的后台已 运行 开启。
在成功证明移动应用程序完整性后，将发布一个短期 JWT 令牌并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用证明失败，JWT 令牌将使用 API 服务器不知道的秘密进行签名。
现在，应用程序必须在每次 API 调用请求的 headers 中发送 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时才为请求提供服务，并在验证失败时拒绝请求。
一旦移动应用程序不知道移动应用程序证明服务使用的秘密，即使应用程序被篡改，也无法在 run-time 对其进行逆向工程，运行有根设备或通过连接进行通信，这是一个人在 th 的目标中攻。
Approov（我在这里工作），移动应用证明服务已经作为 SAAS 解决方案存在，它为多个平台提供 SDK，包括 iOS、Android、React Native 和其他。集成还需要在 API 服务器代码中进行少量检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器来说是必要的，以便能够决定处理哪些请求以及拒绝哪些请求。
结论
最后，为了保护您的 API 服务器，必须根据您要保护的内容的价值以及该类型数据的法律要求来选择解决方案，例如欧洲的 GDPR 法规。
所以使用 API 钥匙听起来像是锁上家门并将钥匙放在垫子下面，但不使用它们就像把车停在车门关着一样，但钥匙在点火。
我创建了一个 Restful API、一个网站（Rails 上的 ReactJS/Ruby）和一个移动应用程序（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 并在那里发出请求而不是获取？
如果你在节点上开发（我猜你是），这应该有效：
在 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_ 写入参数的前缀，以便在 React 中成功调用。
谁和什么正在访问 API 服务器
首先我想弄清楚 WHAT 和 WHO 正在访问 API 服务器之间的区别。
WHO 是移动应用程序的用户，您可以通过多种方式对其进行身份验证、授权和识别，例如使用 OpenID 或 OAUTH2 流程。
现在您需要一种方法来识别什么 正在调用您的API 服务器，这里的事情变得比大多数开发人员想象的更棘手。 WHAT 是向 API 服务器发出请求的东西，它真的是您的正版移动应用程序，还是机器人、自动脚本或攻击者手动浏览您的 API 服务器有像 Postman 这样的工具？
确定 什么 开发人员倾向于求助于 API 键，通常他们 hard-code 在他们的移动应用程序代码中，有些去额外的一英里并在移动应用程序中计算run-time，因此成为一个动态秘密，而不是以前的方法，即嵌入代码中的静态秘密。
API 键的问题
I already have the validation to process the request if only they have sent a valid API key. But on the website and the app, I am using a master API key that has access to all. I believe that this can be seen in the source file on the website and it can be reverse engineered in the mobile app.
在网络应用程序中，我们只需要使用浏览器开发工具检查源代码，或者右键单击查看页面源代码并搜索 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 密钥并枚举其他攻击向量。
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
因此，任何在客户端运行并需要一些秘密才能访问 API 的东西都可能以不同的方式被滥用，您可以在 this series 篇关于移动 API 的文章中了解更多信息] 安全技术。本文将教您如何使用 API 密钥、用户访问令牌、HMAC 和 TLS 固定来保护 API 以及如何绕过它们。
保卫 API 服务器
but how can I access it on my ReactJS components?
抱歉，我没有足够的知识来帮助您，但请继续阅读以了解可以采取哪些措施来保护您的 API 服务器。
The possible solution that I have for the website is to make the process in the server instead of using AJAX...?
For the mobile app, should I switch to using Swift/Java and make the request there instead of fetch?
移动应用程序或 Web 应用程序应仅与您控制的 API 服务器通信，对第三方 API 服务的任何访问都必须由同一 [=104] =] 你控制的服务器。
通过这种方式，您可以将攻击面限制在一个地方，在那里您可以根据所保护的内容采用尽可能多的防御层。
对于 API 服务网络应用程序，您可以使用多层密集，从 reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) 解决方案开始。
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
所有这些解决方案都基于负面识别模型，换句话说，它们通过识别什么是坏的而不是什么是好的来尽力区分好坏，因此它们很容易出现误报，尽管他们中的一些人使用的先进技术，如机器学习和人工智能。
因此，您可能会经常发现自己不得不放松阻止对 API 服务器的访问，以免影响好的用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们会适当地阻止未经授权的用户。
关于 API 为移动应用程序提供服务的肯定识别模型可以通过使用移动应用程序证明解决方案来使用，该解决方案向 API 服务器保证请求可以被信任而没有虚假的可能性正面。
移动应用认证
移动应用证明服务的作用是在 run-time 保证您的移动应用未被篡改或未被 运行 在已获得 root 权限的设备中被 运行 中的 SDK将与云中的服务 运行 通信以证明移动应用程序和设备的完整性的后台已 运行 开启。
在成功证明移动应用程序完整性后，将发布一个短期 JWT 令牌并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用证明失败，JWT 令牌将使用 API 服务器不知道的秘密进行签名。
现在，应用程序必须在每次 API 调用请求的 headers 中发送 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时才为请求提供服务，并在验证失败时拒绝请求。
一旦移动应用程序不知道移动应用程序证明服务使用的秘密，即使应用程序被篡改，也无法在 run-time 对其进行逆向工程，运行有根设备或通过连接进行通信，这是一个人在 th 的目标中攻。
Approov（我在这里工作），移动应用证明服务已经作为 SAAS 解决方案存在，它为多个平台提供 SDK，包括 iOS、Android、React Native 和其他。集成还需要在 API 服务器代码中进行少量检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器来说是必要的，以便能够决定处理哪些请求以及拒绝哪些请求。
结论
最后，为了保护您的 API 服务器，必须根据您要保护的内容的价值以及该类型数据的法律要求来选择解决方案，例如欧洲的 GDPR 法规。
所以使用 API 钥匙听起来像是锁上家门并将钥匙放在垫子下面，但不使用它们就像把车停在车门关着一样，但钥匙在点火。