Custom sys_attachment Read ACL not evaluated / OOB ACLs still granting access on Engagement attachme
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
16 hours ago
Hi everyone,
I'm working on a requirement to restrict attachment access based on Engagement membership.
Requirement
Users should only be able to read attachments if they have access to the parent Engagement. I created a custom sys_attachment Read ACL that calls a custom Script Include:
answer = new sn_acct_lc.EngagementSecurityUtils().canAccessAttachment(current);
The Script Include validates whether the logged-in user belongs to the Engagement team.
Issue
Even though the custom ACL is present, users can still access the attachment when they shouldn't.
Investigation done
- There are around 20+ OOB sys_attachment Read ACLs in the instance.
- I reviewed multiple OOB ACLs (Employee Center, Universal Task, Interaction, Chatbot, etc.).
Some OOB ACLs call:
new global.AttachmentSecurity().canRead(current);
- Others have table-specific conditions and are not applicable to my use case.
- My attachment belongs to an Engagement record, not HR, Interaction, Universal Task, etc.
- The custom ACL returns false for unauthorized users, but access is still granted.
Questions
- How can I identify which sys_attachment Read ACL is actually granting access?
- Has anyone faced a situation where an OOB Attachment security ACL overrides or bypasses a custom attachment ACL?
- Is there a recommended approach to secure sys_attachment based on the parent record without modifying OOB ACLs?
Any suggestions or best practices would be greatly appreciated.
Thanks!
1 REPLY 1
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
8 hours ago
@salemrajpau You can get answers to all of these questions by simply using Access Analyser application in ServiceNow