It's more of a general question, but What is the recommended way to protect APIs used in SIGN UP processes? Let's say there is these public APIs (No user credential required, only API KEYs);
- find_person(Data about the person trying to sign up), returns if a person already exists or not (no user credentials required AND no sensitive information returned).
- create_person(Data about the person trying to sign up), creates this person into the system (no user credentials required)
Can we have "anonymous" users that have a short-lived JWT token? For example, how can the SPA Web application or Mobile application securely obtain a "per-session" anonymous user? Are Captchas actually helpful in this scenario?
We are already considering:
- API KEY for every application (not per session)
- Rate limiting
- DDoS services to protect the APIs
Any help would be much appreciated.
Thanks
CodePudding user response：
Short Live JWT Tokens
Can we have "anonymous" users that have a short-lived JWT token?
Yes, you can and its recommend that you even do it for logged users. See the Auth0 blog What Are Refresh Tokens and How to Use Them Securely:
This post will explore the concept of refresh tokens as defined by OAuth 2.0. We will learn how they compare to other token types and how they let us balance security, usability, and privacy.
The problem with using tokens for anonymous users or logged in users is that they only identify who is in the request, not what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
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 (anonymous or logged) 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.
Your Possible Solutions
We are already considering:
- API KEY for every application (not per session)
- Rate limiting
- DDoS services to protect the APIs
This are basic security measures that any API should implement, but they will fall short when it comes to give na high degree of confidence to API server that the request is indeed from what it expects, a genuine and untampered version of your app.
You can read more about in my article The Top 6 Mobile API Protection Techniques - Are They Enough?:
In this article we will explore the most common techniques used to protect an API, including how important it is to use HTTPS to protect the communication channel between mobile app and API, how API keys are used to identify the mobile app on each API request, how user agents, captchas and IP addresses are used for bot mitigation, and finally how user authentication is important for the mobile security and api security. We will discuss each of these techniques and discuss how they impact the business risk profile, i.e. how easy they are get around.
The reader will come to understand why today’s commonly used mobile API protection techniques are very naive and not fit for purpose to defend digital businesses against API abuse. API abuse is its various forms is much more commonplace that most businesses realize so it is important to employ the right techniques to maintain revenue and brand reputation.
Other Possible solutions
For example, how can the SPA Web application or Mobile application securely obtain a "per-session" anonymous user?
With web apps its very easy to introspect them and see the API requests and their responses by just using the developer tools on the browser.
For mobile apps more work its required but a plethora of open source tools exist to make it easy and in some cases trivial to the point that even non developers can do it, thus making the task of securing an API server very hard, but not impossible.
So, do to the completely different way how the web and mobile devices work the approaches to secure them will differ.
For Web Apps
Are Captchas actually helpful in this scenario?
Captcha gives you a score to tell you a likely who is in the request is a real human. At the best score it cannot guarantee with an high degree of confidence that what is doing the request is indeed what your API server expects, a genuine and untampered version of your web or mobile app.
To 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, you can read my answer to the question Secure api data from calls out of the app, especially the section dedicated to Defending the API Server.
For Mobile Apps
It's more of a general question, but What is the recommended way to protect APIs used in SIGN UP processes?
Despite not being specifically for the signup process 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.
From that answer the better approach that can be employed is by using a Mobile App Attestation solution that will enable the API server to know is receiving only requests from what it expects, a genuine and untampered version of your mobile app.
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
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.