Skip to main content
J
JU_1032179412-Amethyst
12-Amethyst
October 26, 2022
Solved

How do you make frontend buttons secure?

  • October 26, 2022
  • 1 reply
  • 1471 views

Hi,

 

I have a question. I spend a decent amount of time coding checks if something is allowed to happen. mostly because it is so easy to enable, disabled/hidden buttons.

 

You can just edit this html on the frontend:

 

disabled button. but in the front end I can just remove disabled="" and I can use the button.

JU_10321794_0-1666788864917.png

remove display: none; and you can use the button

JU_10321794_2-1666792742233.png

 

 

Is there a way to disable clicked event on runtime? Or something else that the end user can't change themselves

Best answer by VladimirRosu_116627

Hi @JU_10321794 ,

You need to think about "safe" from a different perspective:

  1. Making back-end services "safe". This means that in each service intended to be used by an User you need to code specific checks that verify if that action is permitted or not. Typically this is done by using the ThingWorx runtime permissions (just set runtime service execute permission for a specific User Group and the platform will enforce this for you). Also note that the visibility concept, that applies at the entity level works to add an additional security check in addition to runtime permissions.
  2. Making front-end services "safe". This means displaying or hiding certain buttons based on the User's role, or in your case disabling them. However, you should assume that ALWAYS a malicious user is able to modify the browser HTML code in order to call a specific platform Service - and this is where the back-end service security comes in place. I would never spend too much time to make the front-end secure in this manner, due to the assumptions above, and instead I would focus on making the back-end services secure for your use-case. Even if you create a mashup per role, where you do not add the buttons, by using network sniffing methods, a malicious user could find out the names of the services that other roles have access to, and try to execute them. Hence, the services must be made secure in the first place.

 

1 reply

P
PaiChung22-Sapphire I
22-Sapphire I
October 27, 2022

You can always route your button click through a Validator (doesn't disable the clicking).

J
JU_1032179412-AmethystAuthor
12-Amethyst
October 27, 2022

Is that safe to do?

If it is not possible to create a trigger event from a validator in the front end it would be safe.

I will have to look in to that.

V
VladimirRosu_11662719-TanzaniteAnswer
19-Tanzanite
November 1, 2022

Hi @JU_10321794 ,

You need to think about "safe" from a different perspective:

  1. Making back-end services "safe". This means that in each service intended to be used by an User you need to code specific checks that verify if that action is permitted or not. Typically this is done by using the ThingWorx runtime permissions (just set runtime service execute permission for a specific User Group and the platform will enforce this for you). Also note that the visibility concept, that applies at the entity level works to add an additional security check in addition to runtime permissions.
  2. Making front-end services "safe". This means displaying or hiding certain buttons based on the User's role, or in your case disabling them. However, you should assume that ALWAYS a malicious user is able to modify the browser HTML code in order to call a specific platform Service - and this is where the back-end service security comes in place. I would never spend too much time to make the front-end secure in this manner, due to the assumptions above, and instead I would focus on making the back-end services secure for your use-case. Even if you create a mashup per role, where you do not add the buttons, by using network sniffing methods, a malicious user could find out the names of the services that other roles have access to, and try to execute them. Hence, the services must be made secure in the first place.

 

    Terms & ConditionsAccessibility statement