SIMPLE APPS
For a simple app it’s ok
It depends on the data you are exposing via this simple app, because in Europe for example GDPR law is very strict for anyone that ends up in a data breach situation for Personal Identifiable Information(PII) due to the lack of security measures, and the complexity of the app doesn’t matter for the law. So be it a simple or a complex app, if you are dealing with PII be sure to apply all best security practices in your app.
THE CHALLENGE
butو what if I want to even the user not be able to use this token, and token work just in my react app ( my website ) ?
Well you bought yourself a very hard problem to solve, and this is dues to the public nature of how the web was built, because in the browser you can just hit F12 or inspect page source to grab the secrets, grab cookies, see what’s is stored in the local database, etc..
Who vs What is Accessing the API Server
For example if john doe visited a website, and website created a token for him, he can copy this token and use it in a third party app or create a bot for calling to API of that website
Before I you can start tackling this huge challenge you must clearly understand the difference between who and what is calling your API server, and for that you can read this article section I wrote, from where I quote this:
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.
If this quote is not clear enough, than go and spend some seconds to read the entire section in the linked article.
Now that you have a clear understand about who(Joe) and what(Third Party App, Bot, Postman, cURL, etc.) is accessing your API server you can start applying as many layers of defenses as you can afford and are required by law for your data.
DEFENDING THE API SERVER
I want create an api that even its users can not use their tokens out of my app frontend for calling to the api
Like medieval castles, API defenses are done in layers:
- Secure transport layer by using only HTTPS, and you can do it for free with LetsEncrypt.
- Add security headers, check them with a tool, and enable a report uri on them to know in real-time the violations happening in the browser.
- JWT encrypted tokens(JWE) by preference or at least signed tokens(JWS)
- Obfuscate your Javascript with at least an open source tools, e.g javascript-obfuscator.
- Sign the request with an HMAC and use the Web Cryptography API to help you with that.
- Use reCAPTCHA V3 from Google or similar tool from other vendor. This type of recaptcha doesn’t require user interaction.
- Web Application Firewall(WAF) in front of your API server.
- User Behavior Analytics(UBA), that will use Artificial Intelligence(AI) try to tell apart the who from the what.
So what is the way to do this ? ( secure api against calling out of the specific web app )
So even if you apply all the security layers in the above list, you cannot truly lock down your API server to your React app, but you will making it indeed much harder to bypass, just like you already notice that some do:
Some of the applications are doing this but I don't know how, for example telegram or twitter or ...
Now you may say that WAF and UBA solutions are out of your pocket range, then my advice is that at least you put a CDN in front your API server, because some offer for free some security benefits, but I have to say they protect better traditional web sites, that have a dedicated backend, not an API, but hey something is better then nothing.
So in the end is all about making more time consuming to hack your API server and React app in order to deter the common script kids and less skilled hackers, because they are just after the easy targets, aka the lower hanging fruit. Bear in mind that skilled hackers will always find a way through, but this ones are looking for high valuable targets, aka the fruit in the top of the tree, that is not easy to get, even with a ladder ;).
GOING THE EXTRA MILE
If you want go ahead fully charged to protect your API server then you need to follow the OWASP projects:
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.
So you want to ensure that you don’t have any of the common TOP 10 vulnerabilities in your API.
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.
Using will allow you to identify all attack vectors and hardening your API server and web app to be more difficult to hack, but unfortunately will never be impossible to do so.
LINKS REFERENCES
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG).
We give people the digital certificates they need in order to enable HTTPS (SSL/TLS) for websites, for free, in the most user-friendly way we can. We do this because we want to create a more secure and privacy-respecting Web.
There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it’s important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.
We are the best real-time monitoring platform for cutting edge web standards. Our experience, focus and exposure allow us to take the hassle out of collecting, processing and understanding reports, giving you just the information you need. Did you know your customers’ browsers can automatically send you all sorts of useful information about the security profile of your site?
JSON Web Encryption (JWE) is an IETF standard providing a standardised syntax for the exchange of encrypted data, based on JSON and Base64.[1] It is defined by RFC7516. Along with JSON Web Signature (JWS), it is one of the two possible formats of a JWT (JSON Web Token). JWE forms part of the JavaScript Object Signing and Encryption (JOSE) suite of protocols.[2]
A JSON Web Signature (abbreviated JWS) is an IETF-proposed standard (RFC 7515) for signing arbitrary data.[1] This is used as the basis for a variety of web-based technologies including JSON Web Token.
This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes an API for applications to generate and/or manage the keying material necessary to perform these operations. Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications.
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.
WAF – Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
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.