Securing client side code of react application

Question

I'm developing application with react and all the main logic is on the client side. I want to force users to use the application only if they paid for the app subscription.

Are there any methods to prevent(or harden the ability to remove certain restrictions/api calls etc) users to access the app without paying? I was thinking of authentication obfuscation, to make it hard to delete a simple check of auth(if authenticated - proceed, otherwise - block), but this is very simple. Are there anything else I can do / you can suggest?

Thanks

Answer 1

No, there isn't any foolproof way for securing your code client-side. This is essentially the same problem that DRM has tried and failed to solve. You can obfuscate your code, but that will only make it more difficult to reverse-engineer. With sufficient skill and effort, someone will eventually be able to crack it. And the crackers only have to win once - as soon as one person manages to bypass your client side checks, they can publish it on the internet and everybody else can profit from it (except you of course :).

The solution is simply to move (at least some critical parts of) your code server-side.

Answer 2

You cannot prevent reverse engineering of the client code. You can obfuscate it and make it harder for many users. But if somebody sees that the benefits of reverse engineering are higher than the costs needed for it, then they will of course reverse engineer it and implement work arounds that they need.

If somebody works it around just to circumvent some restrictions or to get some payed services for free, this is only one problem.

Another important aspect is security. Even if users don't want to break your code for their own benefits, it can be attractive for attackers. For instance, one of your users may decide to attack some other users. First they would reverse engineer your code. Depending on your logic there can be a possibility of impersonation. I.e. the attacker can execute some logic in the name of other users: The attacker can send requests to your server and obtain some sensitive data of other users, modify the data of other users, execute some important operations in the name of other users. You cannot prevent it.

That's why I'd suggest you to change your approach as follows:

• Implement all the logic on the server
• On the server don't trust client and validate every request:
  • Check if user is authenticated
  • Check if the user has permission to execute particular operation
  • Check if the data in the request are valid
  • Etc.
• Duplicate some logic on the client only if it improves usability

For instance, user wants to spend $1000, but has only $900 on the account. You should always check this on the server side. But if the check is simple, you can duplicate it on the client side. In such case is user enters 1000, you can display validation message immediately, without sending request to the server. But if user breaks client code and sends 1000 to your service, your service should not trust the client request and should perform all validations needed in your business logic. Thus requests from malicious users will be processed safely in any case and the friendly users will get a better performance.

I suggest either not to duplicate the logic at all, or to keep the amount of such logic on the client side as small as possible, because each time you change or extend the logic on the server side you will have to adjust also the logic on the client.

Answer 3

Consider splitting your React application into several SPAs. Each SPA is rendered by its own script bundle. For example you can have Login SPA rendered by login.js bundle and the rest of the application catered for by the App SPA rendered by app.js bundle.

The first bundle would allow users to login. After that their identity is established and the payment status is retrieved from a database. The link to the next webpage with the paid-only functionality will be conditionally shown to paid users, otherwise the link will be hidden but still easily discoverable by inspecting HTML via Page Source browser's menu. Following this link will make the webrowser load the second SPA which calls the API endpoints for the paid users and contains webpages restricted to the subscription.

Are there any methods to prevent(or harden the ability to remove certain restrictions/api calls etc) users to access the app without paying?

The webserver will refuse to serve the app.js bundle in case of a non-paying user.

As a practical example of a React app split into two SPAs with two script bundles see demo website and the Crisp React solution. The demo does not make the second bundle download conditional but this functionality can be easily added.

P.S.

@winwiz1, do you mind to explain how is this different than splitting the code with protected routes?

I assume it's about the difference between obfuscation and bundle/URL rotation.

Obfuscation

Doing it once is not a reasonable option. Someone can customize an existing deobfuscator or write a custom one and post a hack on some forum. You can keep changing the obfuscation technique. If you do it cheaply (for example change the constant used to XOR the ‘protected’ code), then a decent deobfuscator embedded into a hack can pick it up automatically. If you do it in-depth then continuing doing it over and over again would be expensive and likely not a viable option.

Bundle/URL rotation

Financial institutions exchange nightly batch transactions using encryption with complimentary hardening achieved by making URLs non-public. And they enhance security by rotating encryption keys. In your case the URL is public so you could achieve/enhance hardening by rotating URLs.

For this to work, the client-side caching of the HTML (that contains references to the script bundles) will have to be disabled, as is the case with the demo website and the solution mentioned above. The solution already uses bundle names that include hashes and generates HTML automatically. The only outstanding task would be to rotate URLs by inserting some GUID into it.

The difference

The difference will become obvious if you try to estimate the costs (time and efforts) required to implement obfuscation vs bundle/URL rotation, though this requires a good grasp of both approaches. The next step would be to pretend to be a hacker and consider the practical solutions aimed at defeating obfuscation or bundle/URL rotation. For each solution consider the implementation with related complexity, costs and risks. Which would obviously depend among other things on the method of supplying the non-paid users with the hack, whether it’s once off posting to an underground forum or requires to additionally have continuing online presence - to keep logging in to get new bundles with rotated URLs, to keep making these available to non-paid user base via some online notification mechanism utilised by the distributed hack etc.

---

The whole issue is about authentication (and getting user identity with payment status) folowed by authorization (whether to expose some functionality or not). As already noted by others, it's a wrong approach to try to enforce either on the client side. The enforcement should be on the server side complimented by additional security measures on both sides because good security is always multilayered.