Frontend communicates to backend. I am a developer of frontend and backend. I want to protect my app (prohibit end user from using my app without paying). The only thing I have in mind is to have some middle point, some my server. Frontend send some encoded request to my server, there request is being transformed in a form, that backend could understand. and only then backend can answer to frontend directly without my server as intermediary in communication chain. Client make request to my server, but get data directly from backend which is located on his side. I am not getting any private client information, but I have ability to protect app. Is it correct way? How it is usually done? Frontend - react app, backend - php.


My question in another words. I've created an app. It consits of two parts: frontend (React) and backend (Laravel). I would like to make it paid for end users. How it is usually done? Usually you put backend on some cloud server (Amazon for example), then users log in to your frontend and use your app (saas). Thus your app is good enough protected: backend is on server, to which only you have access. My app should be fully installed on client's server, both: frontend and backend. So the client can see backend code and frontend code. I need somehow to protect my app in such situation. Above I described my thoughs about how I could do it.

  • 2
    I don't understand your scenario TBH. Maybe try to describe it more and split your text into a couple distinct paragraphs.
    – The Fool
    Feb 10, 2021 at 17:05
  • Ok, thank you, I'll extend my question.
    – John Smith
    Feb 10, 2021 at 18:15
  • You can't. Microsoft's been trying this for 25 years with Windows. It hasn't worked for them. It won't work for you.
    – vidarlo
    Feb 19, 2021 at 16:14
  • When you say the client can see the backend code, can they modify the source code? Or are you saying that they just have access to it and can see what is goign on?
    – Limit
    Feb 19, 2021 at 17:21
  • Also, while your application is running locally, can you make requests to a central server? Say for authentication/authorization?
    – Limit
    Feb 19, 2021 at 17:21

2 Answers 2


This is always a tricky question, and from an attackers view, it is always possible to reverse engineer your "backend", if you provide it to run locally at the attackers server.

You could use some obfuscators and anti debugging frameworks (usually one doesn't implement this from scratch) to make it more difficult to get the data out of the app, however it doesn't make successfull attacks impossible but depending on the value of your "backend" logic it may be enough protection. But using function hooking techniques it may not even be necessary to reverse engineer your code.

If your backend is of high value, there won't be a suitable solution where you run it in an untrusted environment.


Broadly speaking, you're just trying to implement DRM. DRM is fundamentally impossible to make truly secure - you can't give a user the ability to run a program / open a file / etc. without giving the ability to enable somebody else to do so - and the vast majority of efforts to implement it fail to do anything useful. Usually they just provide a little challenge for some reverse engineer who will then immediately post the cracked version for distribution online (fun fact: on some games that were released on two platforms, one with DRM and one without, the cracked version of the DRM-encumbered version got pirated more than the one that didn't even need cracking).

Your specific proposed scheme is a form of "always online" DRM, where the app constantly has to communicate with an external server to verify that it's allowed to do things. It's easy enough to implement (for example, the client could hash the request with a timestamp, send the hash to your external server, and get back a digital signature computed with a private key the deployed app doesn't have; the signature is then sent, along with the request, from client to backend, and the backend verifies the signature using the corresponding public key). The question is, is it worth it? In addition to not actually solving the DRM problem (a reverse engineer can just strip out the check from the local server), it introduces some serious reasons somebody might not want to use your product: the product is unusable if your external server goes offline for any reason, and the local (on-premises) server needs to be exposed to the Internet (avoidance of which is usually one of the main reasons for on-prem deployments).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.