Best practice for securing web API endpoint

Question

This is a question about a best practice for securing a Web API endpoint.

Say, I am working for a bank that lets users use a mobile app. I am a developer working on the mobile app for that bank. The app gets OAuth access token and access a web API hosted by the bank. The app has been released.

A regular user who has a valid account in the bank installs the mobile app. Through the mobile app, the user can view the balance, transfer money, etc.

This user has a dev skill and noticed that he can get the access token after he signs in to the bank with his user name and password.

Because this user has a valid account for the bank, the access token is valid to call the API endpoints. The user does trial and error in his Visual Studio to figure out what requests need to be sent to get a valid response from the API. He can refresh access token as many times as needed with the official mobile app manually and eventually finds a way to make valid calls against the API from his dev tool.

Question is, are there any mechanisms that can be utilized to prevent the user from calling the endpoint without going through the official mobile app? The web API can be marked with [RequiredScope] attribute, for example, but if he was able to sign in, should he have all the permissions to do what the normal users are allowed to do, such as transferring money?

I have done searches on this topic on the web as it seems to be a common topic, but have not found references yet.

Answer 1

When developing a UI client you should always assume that the user can grab tokens from a mobile app or secure cookies from a web app, then replay them against the API. Both of which are just HTTP headers. This is easy for any semi-technical user to do with an HTTP proxy tool.

SCOPES

APIs should validate the JWT access token received on every request. Then use scopes to prevent access to invalid operations. Eg if an access token without a money_write scope was used to attempt that operation it would fail with a 403 error.

CLAIMS

The main protection is usually always done when the API's logic verifies claims received in the JWT access token. This ensures that the user can never elevate their own privileges. Consider the following example:

sub: hd80423r2f
tenant-id: 123
role: user
subscription-level: silver

If an API receives this, then it would typically apply code to deny access to resources for other users, roles, tenants or subscription levels. In these cases I most commonly return a 404 resource not found for user response.

HIGH PRIVILEGE OPERATIONS

Operations such as money transfer would usually be accompanied by strong authentication with multiple factors, and short lived access tokens. It is common to also involve user consent, perhaps to a particular payment transaction.

Sometimes you need dynamic authorization behavior in APIs, eg only allow a money transfer if strong authentication was used. In these cases claims are used rather than fixed scopes, and this might result in the following extra claims in the JWT access token:

authentication_strength: high
payment_transaction_id: 123

The API's code could then deny access unless runtime claims such as these were also present.

SUMMARY

You cannot authorize based on use of a mobile app, since APIs cannot distinguish between HTTP requests from mobile apps or sent manually. The main thing to ensure is that if a user grabs a token using tools, they can only access the exact same data that they see in their UI user session.

Answer 2

My Answer Context

The web API can be marked with [RequiredScope] attribute, for example, but if he was able to sign in, should he have all the permissions to do what the normal users are allowed to do, such as transferring money?

I will not try to reply to this question because the accepted answer already does an excellent job at it.

My reply will be in the context of helping you to understand how your API may be empowered to have a very high degree of confidence in what is doing the request, therefore more in the context of your other question:

Question is, are there any mechanisms that can be utilized to prevent the user from calling the endpoint without going through the official mobile app?

The Difference Between WHO and WHAT is Accessing the API Server

First, let's distinguish the difference between who is in the request vs what is making the request to your API, and in a series of articles that I wrote around API and Mobile security, I explain it in the article Why Does Your Mobile App Need An Api Key?, where you can read:

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.

When you grasp this idea and it's ingrained in your mindset, then you will look into API security with another perspective and be able to see attack surfaces that you never though they existed before.

Defending the API

Question is, are there any mechanisms that can be utilized to prevent the user from calling the endpoint without going through the official mobile app?

Now that you understand the difference between who vs what is accessing your API server you may want to employ some mechanisms that can help you with making that distinction for each request handled by your API.

For Web Requests

You can learn some useful techniques to help your API backend to try to respond only to requests coming from what you expect, your genuine web app, and to do so I invite you to read my answer to the question Secure api data from calls out of the app, especially the section dedicated to Defending the API Server.

You can also use the fingerprintjs library to help you to have a more high degree of confidence that what is doing the request is indeed a genuine browser:

FingerprintJS is a browser fingerprinting library that queries browser attributes and computes a hashed visitor identifier from them. Unlike cookies and local storage, a fingerprint stays the same in incognito/private mode and even when browser data is purged.

For Mobile Apps

To identify with a very high degree of confidence that what is doing the request is indeed your genuine and unmodified mobile app I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution, where you will find that the Mobile App Attestation may be the best fit to give you such guarantees.

Do You Want To Go The Extra Mile?

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

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.

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 Web Apps

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.