Updating read only fields using browser console or Inspect

[ServiceNow10sun]

Hi All,

Users are updating read only fields using F12 or Inspect or browser console in incident or change request forms , is there any solution in ServiceNow to restrict this so that no one can change  read only fields in any form.

The developer tool available in browser is allowing to overwrite ACLs, UI policies. 

[Bhavya11 · Accepted solution]

Hi @ServiceNow10sun ,

Use Data policy instead. This will enforce it on DB level.

If this helped please like and mark it as an accepted solution. 

Thanks,

BK

[Bhavya11 · Accepted solution]

Hi @ServiceNow10sun ,

Use Data policy instead. This will enforce it on DB level.

If this helped please like and mark it as an accepted solution. 

Thanks,

BK

[John Dahl]

For what it's worth, I believe Data Policies operate at the application tier and not on the database itself... but it is server-side.

[Ankur Bawiskar · Accepted solution]

@ServiceNow10sun 

the only way is to use Data policies

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Francis Cavaciu]

If we are sticking to OOTB methods then, from testing this in my PDI both, ACL and Data Policies will prevent the users from updating the record if they bypass the Client side Read Only functionality. Both of these methods are heavy handed but will protect your read only data. (*as @Community Alums mentioned below you could also use a Business Rule that compares the current and Previous values, but this won't apply any indication to the end user that the field shouldn't be edited so will need to be coupled with another method, but might suit your purpose so is a good shout and worth noting).

It is worth noting that these methods do not prevent the user updating the value in the form on the client but instead stop the updated value being applied on the server side (so essentially block the forced in value from being written to the record on the database).

If you want to enforce something client side then you might try, in addition to the above, setting up a client script that will look for changes to the field on the client side and give a warning message back while also resetting the field to it's original value. This option is going to carry more technical debt, as the script will need to be maintained, but if it's the changing of the values on the client side that is causing the issue then this might be worth considering. (*I've added an example of this below for you as a starting point)