How to secure own backend API which serves only my frontend?

Question

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.

Embattled

When you say frontend, do you mean a client - like a javascript app running in a browser or a mobile app or something? – Eyler

possible duplicate of https://mcmap.net/q/373624/-securing-express-api – Eyler

Answer 1

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?

In order to identify the WHAT, developers tend to resort to an API key that they usually sent in the header, in a cookie or hidden in the javascript code of their web app (static secret embedded in the header or in the code). Some of them even go the extra mile and compute it at run-time in the web app, thus becomes a dynamic secret.

PRIVATE APIs

No matter if an API doesn't have public accessible documentation or if it is protected by any kind of secret or authentication mechanisms, once it's accessible from the internet, it's not private any-more, thus can be accessed by anyone who knows where it lives and enumerating each endpoint is as easy as using the network tab in the browser 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 these articles were 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.

Megass

noob question, cant you create a public key private key pair such that your server has the private key and the api user needs to send the public key each time in a request? and somehow verify if they match – Mandeville

You can, but then the key is public, thus anyone can get it by reverse engineer the app using it or by doing a MitM attack. – Megass

Thank you @Megass for the indepth answer. I'm still confused as to why this then is not a bigger headache especially for social media sites. If anyone can create a frontend for, e.g. Facebook or Twitter, then what's preventing them? Or an email client for that matter. You can collect tons of logins that way and still deliver the legitimate content from the server. – Binette

Answer 2

1. Look into CORS. And make sure your server only allows access to specific origins.

2. If your JS is requesting data via XMLHttpRequest then on the backend - check if the X-Requested-With header is present and set to XMLHttpRequest. Without a proper CORS handshake this header will be absent.

That being said, this will only protect your API from being used by other front-end apps or from being accessed directly from a browser address bar - because browsers respect CORS. People can still forge requests programmatically/CLI and set headers to whatever they want.

So this is not actually "securing" just a way to prevent abuse & hotlinking

Gorgon