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

[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

[Lisa71]

Then using gliderecord API, the developer can allow anyone to access any data even the developer him/herself doesn't have access to that table, right?

[its_SumitNow · Accepted solution]

@Lisa71  

Yes, exactly right!

When a developer writes server-side code with GlideRecord , that code runs with system privileges and bypasses ACLs.

This means:

1. The developer can query ANY table - even tables they personally don't have access to
2. Any user executing that code can see the data - regardless of their ACLs

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