How to identify the app or website which calls an API endpoint?

We are making an API in PHP. We want the API endpoints to be called only by some specified apps and websites(Not via Postman or any similar software). We have tried to send some authentication key with the call but there are tools which can be used to get the entire code even from a signed APK(tested on the apk of whatsApp), so the key could get leaked.

So, we are trying to figure out if there is a way to identify the caller app or website to our API endpoint then we would verify the identity in PHP and give the response accordingly.

Is there any way to achieve this? If not, then is there any other work around?

Thanks in advance.

THE CHALLENGE

We want the API endpoints to be called only by some specified apps and websites(Not via Postman or any similar software).

Well you got yourself in a huge challenge, and a very though one to solve.

Before I delve in details I can say that it's easier to defend an API that serves only mobile apps then an API that serves both mobile apps and web apps.

As a spoiler alert I can say that for a web app the API server best chance is to employ Artificial Intelligence to defend against no genuine requests, while for a mobile app the solution is more effective and simple, when the API server is able to attest that the mobile app doing the request is the genuine and unmodified one.

REVERSE ENGINEERING

The nature of how the web was built makes it very easy to introspect the code in the client side, aka you just need to hit F12 or right click to view the page source of a page, thus easy to reverse engineer any self defending code or to extract any secrets used to identify the app to the API server.

For mobile apps it's not so easy, but it's not that hard to, because we have excellent open source tools to help us with that, like the Mobile Security Framework(MoBSF) that aggregates several tools under one web interface, that will make it a breeze to reverse engineer and extract the source code and secrets of a signed APK, just as you have achieved with the What's App:

We have tried to send some authentication key with the call but there are tools which can be used to get the entire code even from a signed APK(tested on the apk of whatsApp), so the key could get leaked. 

Secrets in a mobile app can be made hard to extract via static binary anlysis as I show in this article:

During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.

The above article shows how to use the native JNI/NDK interface to hide the secrets in C code, thus making it very hard to extract, but then you can't do it via static analysis, you do it dynamically with a MiTM Proxy attack, as I describe in this other article:

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.

THE DIFFERENCE BETWEEN WHO VS WHAT IS ACCESSING THE API SERVER

So, we are trying to figure out if there is a way to identify the caller app or website to our API endpoint then we would verify the identity in PHP and give the response accordingly.

So with all this tooling and easy access to reverse engineer an app, it becomes very challenging for the API server to differentiate Who is in the request from What is doing the request, and understanding the difference between Who and What it's vital for a developer be able to define a security strategy for it's API servers and apps. Once this is a concept that, more often than not, is misunderstood by developers, I recommend you to read this section of an article I wrote that explains it in more details, and from where I quote:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

So think about the Who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the What as the software making that request in behalf of the user, like Postman or cURL.

With this difference cleared out you are now in a better position to make decisions regarding how you gonna tackle the security of your API server and apps.

IDENTIFYING THE WHO AND THE WHAT IN THE REQUEST

Is there any way to achieve this? If not, then is there any other work around?

To identify the Who in the request you can resort to the traditional authentication and authorization mechanisms or going with OAuth2 or OpenID Connect.

To identify the What in the request is where it resides the challenge, because your API server needs to differentiate the Who from the What, and some advanced approaches will use User Behavior Analytics(UBA) to achieve this.

An example of an UBA solution is [Google reCAPTCHA V3], that doesn't require user interaction and gives a score to the API server in how likely the request comes from a Human or not.

While this works in a best effort basis to differentiate humans from machines, it's not able to offer a very high degree of confidence that you will not run in false positives, but UBA's solutions are your best chance for an API server serving web apps

For an API server serving mobile apps we can leverage the Mobile App Attestation concept to have an effective way of knowing What is doing the request, and I recommend you to go and read this answer I gave for the question How to secure an API REST for mobile app?, that will advise you into having a final solution looking like this:

Read the answer I linked to understand how the Mobile App Attestation will allow to remove secrets from the Mobile App, and give your API server an high degree of confidence in knowing What is doing the request.

DO YOU WANT TO GO THE EXTRA MILE?

In any response to a security question I laways like to reference the excellent work from the OWASP foundation.

For Web Apps

OWASP Web Top 10 Risks

The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.

The Web Security Testing Guide:

The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

LINKS REFERENCES

Google 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.

...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.

UBA - User Behavior Analytics:

User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.

Mobile Security Framework

Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.

OAuth2

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.

OpenID Connect

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. OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.

JNI/NDK:

Using Android Studio 2.2 and higher, you can use the NDK to compile C and C++ code into a native library and package it into your APK using Gradle, the IDE's integrated build system. Your Java code can then call functions in your native library through the Java Native Interface (JNI) framework.