如何保护我的后端不被其他未经授权的前端应用程序访问？我在谷歌上搜索了一下，找不到一个能给出完整解决方案的解决方案。像Instagram、Facebook这样的公司是如何阻止未经授权的请求的？我读到SSL密钥可以通过前端反向工程找到。我是一个傻瓜，正在为一个项目建立社交网络。请引导我。
假设
如何保护我的后端不被其他未经授权的前端应用程序访问？
关于前端应用程序，我认为你指的是移动和网络应用程序，一旦我的专业知识更多地涉及移动应用程序和API安全，我将专注于移动，但我会给你一些指向网络应用程序的指针。
残酷的事实
我在谷歌上搜索了一下，找不到一个能提供完整解决方案的解决方案。
让我告诉你一个残酷的事实，那是因为它不存在。现有的是深度防御，你可以应用尽可能多的层来保护你的后端。
世界卫生组织和什么正在访问你的后台之间的差异
开发人员普遍认为，将https与用户身份验证结合使用，无论是与OAUTH提供商、您自己的JWT实现，还是与传统会话和cookie结合使用，都足以保护后端免受未经授权的访问，但这远不是100%有效的，因为首先，用户身份验证仅识别世界卫生组织正在访问后端，用户而不是什么在访问它。
您可以考虑什么，因为这是您的真实应用程序代表世界卫生组织执行请求，即使出示有效令牌也是如此？或者是来自带有被盗代币的自动脚本的请求，还是来自Postman这样的工具的请求？您可以在我写的关于API密钥的文章的这一部分中阅读更多内容。
不过，逆向工程可能比你更容易
我读到SSL密钥可以通过反向工程前端找到。
如果前端是一个web应用程序，那么在上面找到任何秘密都很简单，只需按F12即可访问浏览器中的开发人员工具，或者右键单击即可检查页面源。
如果前端是一个移动应用程序，那么一些开发人员可能会认为他们是安全的，因为移动应用程序是作为二进制文件发布的，但这是一种错误的安全感，因为有很多工具可以对它们执行静态二进制分析，您可以阅读我写的另一篇文章，了解如何使用移动安全框架从移动应用二进制文件中提取API密钥。
如果静态二进制分析还不够，那么在攻击者控制的设备中，他可以执行MitM(中间人)攻击，拦截应用程序和后端之间的所有通信。我有一篇关于移动应用程序背景下的MitM的文章，你可以在这里阅读更多信息，在这里你将学习如何使用开源工具mitmproxy窃取API密钥，或者他们可以通过在运行时挂接工具框架来采用更高级的方法，例如Frida:
将您自己的脚本注入黑盒进程。挂钩任何函数，监视加密API或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都没有编译步骤或程序重新启动。
大人物如何防守他们的后场
像Instagram、Facebook这样的公司如何阻止未经授权的请求？
他们将使用某种短期令牌或其他机制来识别用户，但正如我已经提到的，这只是为了识别请求中的世界卫生组织。为了让他们知道是什么在做请求，他们可以求助于机器学习和人工智能对传入的请求执行用户行为分析(UBA)，以检测异常的人类行为并阻止它们，你可以在维基百科上阅读更多信息：
Gartner定义的用户行为分析(UBA)是一个关于检测内部威胁、定向攻击和金融欺诈的网络安全过程。UBA解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。[1]UBA不是跟踪设备或安全事件，而是跟踪系统的用户
由于您可以阅读UBA跟踪人类，换句话说，请求中的世界卫生组织。他们这样做是为了区分世界卫生组织和是什么在做请求，正如你可能认为的那样，这很容易出现误报，因此应用于此类系统的政策规则需要考虑到这一点。
可能的解决方案
我是一个noob，正在为一个项目建立社交网络。请引导我。
适用于Web应用程序
虽然UBA解决方案容易出现误报，但它们可能是为网络应用程序提供后端服务的最佳解决方案。推出自己的UBA解决方案将非常昂贵，因为它需要大量的资源、专业知识和时间，而购买商业解决方案可能超出预算，因此您最好的选择可能是谷歌reCAPTCHA V3:
reCAPTCHA v3可以帮助您在没有用户交互的情况下检测网站上的滥用流量。reCAPTCHA v3不会显示CAPTCHA挑战，而是返回一个分数，以便您可以为您的网站选择最合适的操作。
适用于移动应用程序
为了保护为移动应用程序提供服务的API后端，我建议您阅读一系列关于移动API安全的博客文章，其中您将了解如何实现和绕过多种防御，如OAUTH JWT令牌，您还可以阅读其他系列博客文章，这些文章将向您展示一个虚构的应用程序和虚构的攻击者击败API密钥、，以及与HMAC签署的请求。
对于移动应用程序的后端，保护其免受未经授权请求的最佳方法是使用移动应用程序验证解决方案，简言之，这将允许后端识别WHAT正在进行请求，而不需要在应用程序中提供任何类型的秘密，如传统的API密钥，在一篇关于证书固定的文章的这一节中，我将更详细地介绍移动应用程序认证的作用，您可以阅读：
移动应用验证服务的作用是验证发送请求的内容，从而仅响应来自真实移动应用实例的请求，并拒绝来自未经授权来源的所有其他请求。
为了了解向API服务器发送请求的内容，移动应用验证服务将在运行时高度自信地识别您的移动应用是否存在、未被篡改/重新打包、未在根设备中运行、未被仪器框架(Frida、xPosed、Cydia等)钩住，并且不是中间人攻击(MitM)的对象。这是通过在后台运行SDK来实现的，该SDK将与云中运行的服务进行通信，以证明其运行的移动应用程序和设备的完整性。
在成功证明移动应用程序完整性的基础上，将发布一个短时间生存的JWT令牌，并使用只有API服务器和云中的移动应用程序认证服务知道的秘密进行签名。在证明失败的情况下，JWT令牌将使用不正确的密钥进行签名。由于移动应用程序不知道移动应用程序验证服务使用的秘密，因此即使应用程序已被篡改、在根设备中运行或通过作为MitM攻击目标的连接进行通信，也不可能在运行时对其进行反向工程。
移动应用程序必须在每个API请求的头中发送JWT令牌。这允许API服务器仅在能够验证JWT令牌是使用共享密钥签名的并且尚未过期时才为请求提供服务。所有其他请求都将被拒绝。换言之，有效的JWT令牌告诉API服务器请求的内容是上传到Google或Apple商店的真实移动应用程序，而无效或丢失的JWT代币意味着发出请求的内容未被授权，因为它可能是机器人程序、重新打包的应用程序或进行MitM攻击的攻击者。
使用移动应用程序验证服务的一个巨大好处是其主动和积极的身份验证模型，它不会产生误报，因此不会阻止合法用户，同时也可以阻止坏人。
再跑一英里
在安全问题上，我总是喜欢最后推荐OWASP:的出色工作
网络安全测试指南
OWASP Web安全测试指南包括一个"；最佳实践"；用户可以在他们自己的组织中实现的渗透测试框架；低电平"；渗透测试指南，描述了测试最常见的web应用程序和web服务安全问题的技术。
移动安全测试指南
《移动安全测试指南》(MSTG)是一本关于移动应用程序安全开发、测试和逆向工程的综合手册。
我会努力让您从正确的方向开始。
如何保护我的后端不被其他未经授权的前端应用程序访问？
您可以通过发布访问令牌来保护您的服务器。用户获得有效令牌的唯一方法是使用有效的用户名和密码进行身份验证。
通常，令牌设置为在一段时间后过期。如果您正在寻找交钥匙解决方案，JSON web令牌是一个很好的起点。更多信息请点击此处：https://jwt.io/
我在谷歌上搜索了一下，找不到一个能提供完整解决方案的解决方案。像Instagram、Facebook这样的公司是如何阻止未经授权的请求的？
Facebook使用访问令牌。https://developers.facebook.com/docs/facebook-login/access-tokens/
我读到SSL密钥可以通过反向工程前端找到。
访问令牌不能进行反向工程，因为它们没有"硬编码"到前端。访问令牌通过身份验证从后端检索。此外，代币通常会在一段时间后过期。如果令牌已过期，则用户必须重新进行身份验证才能接收新的(有效的)令牌。
使用Firebase应用程序检查，您可以保护后端(API)免受未经授权的应用程序的攻击。
每个来自前端Android、iOS、Web或Flutter的请求都会发送生成的令牌，而从后端，我们必须验证该令牌。如果验证，则服务请求，否则返回未经授权的请求。
我已经在Medium上写了详细的文件。https://yogesh-shinde.medium.com/app-check-protect-backend-api-from-unauthorised-requests-3da1ba6d19f1