我已经编写了自己的api，我想将其上传到服务器上，但是我想对其进行保护，因此除了从我的应用程序外，其他任何人都无法访问它，我尝试了slim-basic-auth库，但是它没有用，我不知道为什么 有什么帮助吗？
$app->add(new Tuupola\Middleware\HttpBasicAuthentication([
"secure"=>false,"users" => [
"userher@#" => "passhere#@" ]
]));
您需要做的是从客户端应用程序向服务器应用程序添加变量。类似于APP_KEY或CLIENT_ID，它们允许您的应用连接到服务器。您可以添加加密，以便服务器应用程序只能对其进行解密并识别来自客户端应用程序的请求。
如果您的应用程序是Web应用程序并托管在另一台服务器上，则可以在服务器上实施IP白名单。
但是，如果您的应用是移动设备，则需要像secret_key一样从移动设备传递到服务器。
此致
,我认为您将永远无法隐藏该应用程序正在调用的api网址（具有扎根android设备的攻击者可以轻松拦截流量），如果您的api响应用户特定数据，则可以在请求中添加auth标头在服务器上验证此标头。您还可以使用跨域资源共享（CORS）和SSL来获得额外的安全性。
,您一眼便想拥有一个私有API，将您的Android App锁定到它，并解决API服务器中的代码问题。让我们按照我提到的顺序来解决。
如何保护自己的api免受黑客攻击并使其私有化
好吧，我有一个残酷的事实要告诉你，不存在私有API之类的东西，除非您不将其公开给Internet，也就是只能通过自己不通过的程序在私有网络内部对其进行访问也暴露于互联网。换句话说，如果您的API与互联网之间存在空气间隙，那么它就只能是私有的。
因此，无论API是否没有公共可访问的文档，或者是否受到任何类型的秘密或身份验证机制的保护，从Internet访问一次就不再是私有的，您甚至可以使用提供帮助的工具与发现他们。
您可以在this article section中了解更多信息，我在这里摘录了一些内容：
现在，仅因为您的API文档不是公开的，甚至根本不存在，任何有权访问查询您API的应用程序的人都可以发现它。
感兴趣的各方只需在您的应用程序和API之间设置代理，以监视所有发出的请求及其响应，以便构建API的配置文件并了解其工作原理。
代理工具：
面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理。
因此，这里的教训是，从发布使用API的移动应用程序开始，您就可以认为它现在属于公共领域，因为任何人都可以对其进行反向工程并发现您的“私有” API的工作方式，并使用它来对其进行自动攻击。
我已经编写了自己的api，我想将其上传到服务器，但是我想保护它，因此除了从我的应用程序外，其他任何人都无法访问它
好吧，您为自己买了一件非常艰巨的任务，有人可能会说这是不可能完成的，但是一旦您对该主题进行了足够深入的了解，您将能够理解，您仍有一些探索之路。 / p>
首先，您需要了解 WHO 和 What 在访问API服务器之间的区别，然后学习一些用于保护API服务器安全的最常用技术，最后您将了解到，移动应用认证可能就是您所需要的。
我写了一系列有关API和移动安全的文章，在文章Why Does Your Mobile App Need An Api Key?中，您可以详细了解 WHO 和 WAHT 的区别访问您的API服务器，但是我将在此处提取其主要收获：
什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和标识，例如使用OpenID Connect或OAUTH2流。
因此，请以 WHO 为用户，您的API服务器将能够进行身份验证和授权以访问数据，并以 What 作为软件制造商该请求代表用户。
基本防御措施
现在，您了解了 WHO 与 What 在访问API服务器之间的区别，您可能需要阅读my article，以了解保护安全的基本技术API：
在本文中，我们将探讨用于保护API的最常用技术，包括使用HTTPS保护移动应用程序和API之间的通信通道的重要性，如何使用API密钥识别每个API上的移动应用程序API请求，如何将用户代理，验证码和IP地址用于缓解僵尸程序，以及最终用户身份验证对于移动安全性和api安全性如何重要。我们将讨论这些技术中的每一种，并讨论它们如何影响业务风险状况，即如何轻松解决问题。
更多高级防御
您可以先阅读Mobile API Security Techniques上的系列文章，以了解如何使用API密钥，HMAC，OAUTH和certificate pinning来增强安全性，同时又可以如何滥用它们/失败了。
然后，根据您的预算和资源，您可以采用各种不同的方法和技术来保护您的API服务器，而我将开始列举一些最常用的方法和技术。
您可以从reCaptcha V3开始，然后是Web Application Firewall（WAF），最后如果可以负担得起User Behavior Analytics（UBA）解决方案。
Google 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这样的大数据平台通过允许它们分析PB级的数据来检测内部威胁和高级持久威胁，正在增强UBA功能。
所有这些解决方案都基于否定性识别模型，换句话说，他们通过识别出什么是不好的而不是什么是好的来尽最大的努力将好与坏区别开来，因此尽管存在以下缺点，它们还是容易出现误报的情况其中一些人使用了先进的技术，例如机器学习和人工智能。
因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问以不影响良好用户。这也意味着该解决方案需要进行持续监控，以验证误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户。
关于为移动应用程序提供服务的API，可以通过实施移动应用程序证明解决方案来使用肯定的识别模型，该解决方案可以在对API服务器提出任何请求之前证明您的移动应用程序和设备的运行完整性。
最后，如果您有足够的资源，则可以通过构建自己的移动应用程序证明进一步保护自己的API服务器和移动应用程序，并且可以在this article section中阅读有关其总体概念的信息，从哪里开始我提取了这个：
移动应用程序证明服务的作用是对发送请求的内容进行身份验证，从而仅响应来自真正的移动应用程序实例的请求，并拒绝来自未授权来源的所有其他请求。
为了知道是什么向API服务器发送了请求，移动应用程序证明服务将在运行时高度肯定地确定您的移动应用程序存在，未被篡改/重新打包，未运行在具有根权限的设备中，没有被工具框架（Frida，xPosed，Cydia等）迷住，也不是中间人攻击（MitM）的对象。这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信，以证明移动应用程序及其所运行的设备的完整性。
在成功证明移动应用程序完整性后，将发布并使用一个秘密的短时间JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务才能知道。在证明失败的情况下，将使用错误的机密对JWT令牌进行签名。由于移动应用程序不知道移动应用程序证明服务使用的机密，因此即使在应用程序已被篡改，在有根设备中运行或通过连接通信时，也无法在运行时对其进行反向工程这是MitM攻击的目标。
移动应用必须在每个API请求的标头中发送JWT令牌。这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名且尚未到期时才服务请求。所有其他请求将被拒绝。换句话说，有效的JWT令牌会告诉API服务器发出请求的是上传到Google或Apple商店的真正的移动应用程序，而无效或丢失的JWT令牌意味着发出请求的内容未经授权，因为它可能是机器人，重新包装的应用程序或发起MitM攻击的攻击者。
使用移动应用程序证明服务的一个巨大好处是其主动和肯定的身份验证模型，该模型不会产生误报，因此不会阻止合法用户，同时又阻止了坏人。
因此，通过移动应用证明，您的API服务器可以高度自信地确定该请求来自您期望的内容，是您上传到的原始和未修改的APK Google Play商店。
我尝试了slim-basic-auth库，但没有用，我不知道为什么
我对Tuupola项目一点都不熟悉，但是从Slim API Skeleton的README.md来看，尤其是有关如何get a token然后是{{ 3}}。可以在how to use it找到生成令牌的相关代码，并且要使用令牌保护API路由，可以在routes/token.php找到示例。所有这些都在配置文件routes/todos.php中配置。但是我不得不说，我对它们的态势并没有留下深刻的印象，这是因为它们鼓励通过API端点公开服务器敏感数据，正如我们在config/middleware.php所看到的那样，因此我强烈建议您立即删除所有存在于您项目中的端点。
在我看来，最好的解决方案是通过尽可能多地应用层来进行纵深防御，从而增加通过所有安全层所需的时间，精力和技能，从而避免了脚本失误孩子和偶尔的黑客滥用您的API服务器和移动应用。
因此，您应该在等式，移动应用程序和API的两面都采用尽可能多的技术，例如阅读我链接的文章时所学到的技术：HTTPS，API密钥，用户代理，验证码，速率限制，OAuth，HMAC，证书固定，代码混淆，隐藏秘密的JNI / NDK，WAF，UBA等。
最后，必须根据要保护的内容的价值以及该类型数据的法律要求（例如GDPR法规）来选择用于保护API服务器和Mobile App的解决方案在欧洲。
我强烈建议您，也来看看routes/token.php
OWASP移动安全项目是一个集中式资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制措施，以减少其影响或被利用的可能性。