Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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.

like image 356
Donald Avatar asked Jan 25 '19 16:01

Donald


People also ask

How can I ensure my API is only called by my client?

To ensure a REST API is accessed only by known consumers, client applications use to sign each HTTP request with a secret and then send the resulting signature togheter with the API key to the server.


2 Answers

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.

like image 65
Exadra37 Avatar answered Oct 09 '22 02:10

Exadra37


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

  2. On the backend - check if the X-Requested-With header is present in the request 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

like image 30
Alex from Jitbit Avatar answered Oct 09 '22 01:10

Alex from Jitbit