如何保护自己的仅用于前端的后端API? [英] How to secure own backend API which serves only my frontend?
问题描述
我正在设置一个Web应用程序，该Web应用程序具有一个前端和一个后端，该后端通过RESTful方法与前端soley通信.如何确保后端端点只能由我自己的前端访问，而不能由其他任何人访问?我找不到很多信息.
I'm setting up a webapp with a frontend and a backend that communicates with the frontend soley through RESTful methods. How do I make sure that the backend endpoints are only accessed by my own frontend, and not anyone else? I cannot find much information on this.
推荐答案
如何确保后端端点只能由我自己的前端访问，而不能由其他任何人访问?
How do I make sure that the backend endpoints are only accessed by my own frontend, and not anyone else?
让我在这里告诉您一个残酷的事实...由于 自然，网络是如何设计的.
Let me tell you here a cruel truth... is not possible for a web app, due to the nature how the web was designed to work.
让我们尝试通过深入了解问题来更深入地了解问题 WHO 和什么正在访问您的API服务器之间的区别，以及为什么要私有 API不存在.
Let's try to understand the problem a little more in depth by understanding the difference between WHO and WHAT is accessing your API server, and why private API's don't exist.
WHO 是网络应用程序的用户，您可以通过多种方式(例如使用OAUTH流和/或OpenID)进行身份验证，授权和标识.
The WHO is the user of the web app that you can authenticate,authorize and identify in several ways, like using OAUTH flows and/or OpenID.
通常，OAuth代表资源所有者向客户端提供对服务器资源的安全委派访问".它为资源所有者指定了一种在不共享其凭据的情况下授权第三方访问其服务器资源的过程. OAuth专为与超文本传输协议(HTTP)配合使用而设计，本质上允许在资源所有者的批准下，授权服务器将访问令牌发布给第三方客户端.然后，第三方使用访问令牌访问资源服务器托管的受保护资源.
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect 1.0是OAuth 2.0协议之上的一个简单身份层.它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终用户的基本配置文件信息.
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
现在，您需要一种方法来识别正在调用API服务器的什么，这比大多数开发人员想象的要棘手得多. 什么是向API服务器发出请求的东西，是您真正的Web应用程序，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上乱逛?
Now you need a way to identify WHAT is calling your API server and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server, is it really your genuine web app or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
可以识别什么的开发人员倾向于使用通常在标头中发送的，在cookie中或在其网络应用程序的javascript代码中隐藏的API密钥，而有些则需要付出更多努力并在Web应用程序运行时对其进行计算，从而成为动态秘密，与以前的方法相反，后者是嵌入在代码或标头中的静态秘密.
Well to identify the WHAT developers tend to resort to an API key that usually they sent in the header, in a cookie or hidden in the javascript code of their web app and some go the extra mile and compute it at run-time in the web app, thus becomes a dynamic secret in opposition to the former approach that is a static secret embedded in the code or in the header.
无论API没有公开可访问的文档，或者是否受到任何类型的秘密或身份验证机制的保护，都可以访问一次 从互联网上不再是私有的，因此任何人都可以访问 知道它的位置，并且枚举每个端点就像使用网络一样容易 开发工具中的标签".
No matter if an API doesn't have public accessible documentation or if is is protected by any kind of secret or authentication mechanisms, once is accessible from the internet is not private any-more, thus can be accessed by anyone who knows where it lives and enumerating each endpoint is easy as using the network tab in the the dev tools.
任何在客户端运行且需要一些秘密才能访问API的东西 可以以不同的方式被滥用，您可以了解更多 本系列的 有关移动API安全技术的文章.虽然这篇文章在哪里完成 在移动应用的背景下，他们仍然与网络应用共享通用技术. 他们将教您如何使用API密钥，用户访问令牌，HMAC和TLS固定 用于保护API以及如何绕过它们.
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you can learn more on this series of articles about Mobile API Security Techniques. While this articles where done in the context of a mobile app, they still share common techniques with web apps. They will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed.
混淆会使您的Javascript代码难以理解，这将使逆向工程变得困难，但请记住，并非不可能，因此不要依赖它来隐藏敏感数据，而只是将其隐藏为另一层使得很难理解发生了什么.
Your Javascript code can be made hard to understand by obfuscating it, that will make it hard to reverse engineer, but bear in mind not impossible, thus don't rely on it to hide sensitive data, but only as another layer of making harder to understand what is going on.
您可能还想看看Google的 reCaptcha V3 从而可以区分真实用户 从自动化脚本中获取，而无需用户交互.您需要将其添加到Web应用程序的每个页面中.
You may also want to take a look into the reCaptcha V3 from Google that will allow to distinguish real users from automated scripts without requiring user interaction. You will need to add it to every page in your web app.
reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害. reCAPTCHA使用先进的风险分析引擎和适应性挑战，以防止自动化软件参与您网站上的滥用行为.这样做是在让您的有效用户轻松通过的同时.
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.
另一种更复杂的方法是使用后端使用机器学习和人工智能的User Behavior Anlytics(UBA)工具来防止API滥用，但它们不能100％阻止它.
Another more sophisticated way is to use User Behaviour Anlytics(UBA) tools that employ machine learning and artificial intelligence in the backend to prevent API abuse, but they are not able to block it at 100%.
要解决什么正在访问您的API服务器的问题，您需要使用关于移动API安全技术，reCaptcha V3和UBA解决方案的一系列文章中提到的一个或所有解决方案，并且已接受他们只能使绕过未经授权的API服务器访问更加困难，但并非不可能.
To solve the problem of WHAT is accessing your API server you need to use one or all the solutions mentioned in the series of articles about Mobile API Security Techniques, reCaptcha V3 and a UBA solution and accepted that they can only make unauthorized access to your API server harder to bypass but not impossible.
因此，您可能很难找到和访问您的API，但是却无法将其真正锁定到Web应用程序.
So you can make it hard to find and access your API, but to truly lock it to your web app you can't.
这篇关于如何保护自己的仅用于前端的后端API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
