What's the difference between GlideRecord and GlideRecordSecure?

[Lisa71]

If we use GlideRecord without explicitly requires ACL check, it can get data bypass the ACL check? For example, if a UI action uses GlideRecord to fetch data in table A, then a user without read ACL in table A can view table A's data when pressing that UI action? Thanks.

[PrashantLearnIT · Accepted solution]

Hi @Lisa71 

GlideRecord is the standard, powerful table API for database interaction, while GlideRecordSecure extends it by automatically enforcing Access Control Lists (ACLs) for the current user, making it safer for sensitive data and scoped applications where respecting user permissions (read/write/delete) is crucial; GlideRecord requires manual canRead() checks, whereas GlideRecordSecure handles them implicitly, ensuring compliance without extra code.

Go through this blog for better understanding - https://developer.servicenow.com/blog.do?p=/post/gliderecord-vs-gliderecordsecure/

[TejasSN_LogicX · Accepted solution]

Hi @Lisa71  ,

GlideRecord → does not check ACLs (system-level access)

GlideRecordSecure → checks ACLs for the current user.

So if your UI Action or Script Include runs as a user, always use GlideRecordSecure or check gr.canRead()  

If you use GlideRecord in a server-side script (like a UI Action, Business Rule, or Script Include), it usually runs with system-level access. That means it does not check ACLs by default.

So, even if a user does not have read access to a table, your script can still get and show that data when it runs on the server. If your UI Action sends that data back to the user (for example, showing it in a message or portal), then the user can see information they normally shouldn’t.

To make sure ACLs are checked, you should use GlideRecordSecure instead of GlideRecord. GlideRecordSecure automatically follows the user’s ACL permissions.

aslo check this :

https://www.servicenow.com/community/developer-blog/gliderecordsecure-gliderecord-vs-gliderecordsecu...

https://developer.servicenow.com/blog.do?p=/post/gliderecord-vs-gliderecordsecure/

If you found my solution helpful, please mark it as Helpful or Accepted Solution...!

thanks,

tejas

Email: adhalraotejas1018@gmail.com

LinkedIn: https://www.linkedin.com/in/tejas1018

[its_SumitNow · Accepted solution]

Hi @Lisa71 

Yes, GlideRecord bypasses ACLs by default in server-side scripts.

A user without read access to Table A could view its data through a UI Action that uses GlideRecord.

This was the major drawback with gliderecord , hence we are having GlideRecordSecure API which checks for ACL also

Apart from this You can check out this blog

https://developer.servicenow.com/blog.do?p=%2Fpost%2Fgliderecord-vs-gliderecordsecure%2F 

if my response helps, Please Mark helpful and accept as solution , you can accept Multiple 🙂

Warm Regards

Sumit Yadav

Technical Consultant

[PrashantLearnIT · Accepted solution]

Hi @Lisa71 

GlideRecord is the standard, powerful table API for database interaction, while GlideRecordSecure extends it by automatically enforcing Access Control Lists (ACLs) for the current user, making it safer for sensitive data and scoped applications where respecting user permissions (read/write/delete) is crucial; GlideRecord requires manual canRead() checks, whereas GlideRecordSecure handles them implicitly, ensuring compliance without extra code.

Go through this blog for better understanding - https://developer.servicenow.com/blog.do?p=/post/gliderecord-vs-gliderecordsecure/

[TejasSN_LogicX · Accepted solution]

Hi @Lisa71  ,

GlideRecord → does not check ACLs (system-level access)

GlideRecordSecure → checks ACLs for the current user.

So if your UI Action or Script Include runs as a user, always use GlideRecordSecure or check gr.canRead()  

If you use GlideRecord in a server-side script (like a UI Action, Business Rule, or Script Include), it usually runs with system-level access. That means it does not check ACLs by default.

So, even if a user does not have read access to a table, your script can still get and show that data when it runs on the server. If your UI Action sends that data back to the user (for example, showing it in a message or portal), then the user can see information they normally shouldn’t.

To make sure ACLs are checked, you should use GlideRecordSecure instead of GlideRecord. GlideRecordSecure automatically follows the user’s ACL permissions.

aslo check this :

https://www.servicenow.com/community/developer-blog/gliderecordsecure-gliderecord-vs-gliderecordsecu...

https://developer.servicenow.com/blog.do?p=/post/gliderecord-vs-gliderecordsecure/

If you found my solution helpful, please mark it as Helpful or Accepted Solution...!

thanks,

tejas

Email: adhalraotejas1018@gmail.com

LinkedIn: https://www.linkedin.com/in/tejas1018

[Lisa71]

Thank you, then what do you mean by "system level access", which permission does "system level access" have?

[adityahubli]

Hello @Lisa71 ,

There slightly difference between GlideRecord and GlidRecordSecure .

1)GlideRecord api dont enforce Access Control List (ACL) while performing database operation like read,write,update.It dont check user has required role or not while performing database operation.

Its execution time is less as compared to GlideRecordSecure api .

2)Gliderecord Secure enforce ACL means it check while performing Database operation user has valid roles or not . If dont then denied database operation. It take more execution time as compared to GlideRecord api

You can also refer this Article also :

https://www.servicenow.com/community/developer-blog/gliderecordsecure-gliderecord-vs-gliderecordsecu... 

If this helps you then mark it as helpful and accept as solution.

Regards,

Aditya,

Technical Consultant