cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X

How do you make frontend buttons secure?

JU_10321794
8-Gravel

How do you make frontend buttons secure?

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

1 ACCEPTED SOLUTION

Accepted Solutions

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.

 

View solution in original post

3 REPLIES 3
PaiChung
22-Sapphire I
(To:JU_10321794)

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

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.

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.

 

Top Tags