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.
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 AND WHAT IS ACCESSING THE API SERVER
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
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
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.
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?
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.
PRIVATE APIs
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.
POSSIBLE SOLUTIONS
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.
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.
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 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.
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%.
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.
SUMMARY
So you can make it hard to find and access your API, but to truly lock it to your web app you can’t.