I'm starting a new project in which we will use Client Side Rendering for the frontend. This is my first time working with this kind of technology and I was wondering which would be the best approach to develop non-regular users components (for instance, fragments that only Admins or Moderators should be able to see).

As the application itself will be on the client browser, and it might be a regular user or an admin user, shall we make efforts to "hide" the code to run components that only make sense to admin users to users with enough knowledge to change the web configuration (State, Local Storage...)? Or should we stop caring about how the user manipulates the web page and just rely on the backend managing the role permissions properly?


  • 2
    Compare costs and benefits. This is mostly a business choice, not a technical one. Your backend must prevent giving non-admin users administrative rights anyway, whether those functions are hidden in the frontend or not. Providing different frontends to admins and non-admins incurs a cost, you need to decide whether that cost is offset by the benefits of doing so (what are those benefits anyway except security by obscurity?). Jan 10 at 14:13

If you don't want to create a security issue, you always have to make sure the backend needs to manage permissions properly. However, if the UI does contain elements which make only sense if one has admin permissions, hiding those element is a matter of ergonomics, not a matter of security.

Concerning code for admin tools (which is not directly visible for anyone on the UI): even when the backend seems to be secure, such code may bear a certain risk to expose some internals. A malicious user might use them for exploitation in case your backend has a security bug. So in case you trust the admins more than your "standard users" can reduce the risk for an application to get subject of a security breach.

However, this becomes pointless when you don't trust those admin users more than your standard users. In this case, it does mostly not matter if code for admin tools is exposed to anyone, since you need to make the system equally secure against admins and non-admins.

Ultimately, you need to know your threat model and do some risk analysis the specific application, there is no "one-size-fits-all" answer for this.

  • Thanks for your answer. Just to clarify, when I talk about "hiding", I'm not talking about hiding UI to regular users, but mostly about hiding the code that can be enabled or disabled from the browser dev tools. As in a CSR application the web page runs on the client side, a user with enough knowledge can trivially simulate being an admin and see the UI as if it were so (even if the backend rejects unauthorized requests). I don't know if exposing this functionality and relying only on backend handling the permissions might be consider a bad practice.
    – David
    Jan 10 at 15:33
  • 1
    Nothing to do with security should be controlled "on" the client because /you/ have no control over the client environment. Security must be done server-side, where you can keep a tight rein on everything. Remember, just because you /sent/ the user a chunk of HTML with which to interact /does not/ mean that their next request to your application will come from that HTML! (Do you validate the values that you sent out in HTML SELECT lists? You /should/!)
    – Phill W.
    Jan 10 at 15:41
  • @PhillW. You are completely right. I'm not talking about controlling security on client side, whatever I do I'll make sure backend does reject unauthorized requests. But probably because a lot of years using Server Side Rendering applications I'm afraid I'm missing possible handicaps of exposing admin functionality to the public. I'm not even talking about exposing endpoints. Let's say a phising attack, I'm giving the malicious user the UI to build a realistic admin tool panel which might make the victim be over-confident.
    – David
    Jan 10 at 16:00
  • 2
    @David: even when your backend seems to be secure, I guess the more admin code you expose to the end user, the more likely it gets a malicous user might find a loop hole in case your backend isn't 100% bugfree - at least in theory. However, this becomes pointless when you suspect a malicous standard user working together with an admin. What you ultimately need here is a threat model and a risk estimation.
    – Doc Brown
    Jan 10 at 16:11

Think of Kerckhoffs's principle. You should assume that potential attackers will know your code sooner or later. That's why, if you hide your admin code, you will not increase security.

When you consider admin code, forget about hiding it. Consider only common criteria. For instance, if you put this code to separate module:

  • Will it reduce dependencies between modules and thus will it simplify development and maintenance?
  • Will it improve the stability and testability of this code?
  • Can you avoid loading this module, and if yes, would it improve performance essentially?


When you answer such questions for your specific case, then you will see if it makes sense to hide such code (e.g. by not loading it).

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.