I am planning to create an back end application in JAVA and Spring Boot which has a set of REST APIs. If these APIs are consumed by a single Android application then do I need to secure them using HTTPS (SSL/TLS), JWT token etc.
CodePudding user response：
Should HTTPS be Used in APIS?
I am planning to create an back end application in JAVA and Spring Boot which has a set of REST APIs. If these APIs are consumed by a single Android application then do I need to secure them using HTTPS (SSL/TLS), JWT token etc.
Absolutely Yes.
No reason exists nowadays for not using HTTPS and I talk about why you should use HTTPS 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.
Is HTTPS enough to secure the API?
No, because a lot of reverse engineer techniques and tools exist to byapss the secure communication channel that HTTPS provides between the mobile app and the API server.
A very popular technique is to deploy a Man in the Middle (MitM) attack, that will allow for an attacker to decrypt the HTTPS traffic in a device he controls or have induced the user to install custom certificates, but this can be prevented with the use of certificate pinning.
You can learn more about how a MitM attack is carried out in my article Steal that Api Key with a Man in the Middle Attack:
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.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
Securing HTTPS with Certificate Pinning
To prevent MitM attacks to occur you can deploy certificate pinning on your mobile app, and you can learn more about in my article Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
This article will show you how to use the Mobile Certificate Pinning Generator, an online free tool that will give you ready to use configuration files for Android and iOS with pinning configured.
Simply add the API domain to pin against:
And then copy and paste the configuration into your Android app:
Please be aware of the trade-offs and pitfalls of using static certificate pinning by reading the tool faq tab:
Certificate pinning involves statically embedding the expected pins into the app itself. Changing the pins requires an update of the app to be issued.
The DevOps team rotates the server certificate without communicating it to the developers or fails to coordinate the rotation with the release of a new version of the mobile app containing a new public key pin.
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.
CodePudding user response：
Anything which is exposed on the Internet should be secured. You know that only your app will call your API, but if the API is not secured then anyone can start calling your API and pretend they are your Android app. The malicious actor will be able to do with your API everything that the app could do - read users' data, modify them, etc.
The same goes for HTTPS. Using HTTPS is meant to protect the traffic between your server and your app. It doesn't matter whether you will have only one app consuming the API. If you don't use HTTPS, then anyone can eavesdrop your traffic.