使用自定义角色通过ServiceNow REST API访问sys_script表遇403错误

1. sys_script表的默认访问限制确认 #

是的，sys_script作为ServiceNow的核心系统表（存储脚本代码），默认仅允许admin角色通过REST Table API访问。这是ServiceNow为保护系统敏感资源（脚本逻辑直接影响系统运行）设置的默认安全限制。

2. 导致403的隐藏限制因素 #

你遇到的问题并非表级ACL未生效，而是存在以下隐藏限制：

• 字段级ACL拦截：sys_script表的核心字段（如script、name、sys_id、active等）默认仅对admin开放读取权限。即使表级read ACL通过，只要用户没有字段级的读取权限，就会返回"查询中存在的字段无读取权限"的403错误。
• 系统属性限制：ServiceNow默认启用glide.restrict_high_priority_tables系统属性，该属性会限制非admin用户通过REST API访问包括sys_script在内的"高优先级系统表"，这是一层全局级别的访问拦截。
• 不存在跨域保护导致的问题，跨域错误通常表现为CORS相关提示，而非字段权限类的403。

3. 除Admin外可访问的角色 #

ServiceNow没有提供默认的非Admin角色直接拥有sys_script的REST访问权限。你需要通过自定义ACL配置，让指定角色（如你的x_myrole）获得访问权限，或使用security_admin这类高权限角色（但不推荐，权限过大）。

4. 非Admin用户实现访问的具体步骤 #

步骤1：配置字段级Read ACL #

针对sys_script表中你需要访问的所有字段，创建字段级的read ACL：

• 导航至系统安全 > 访问控制列表 > 新建
• 表选择sys_script，操作选择read，类型选择字段
• 字段选择需要访问的字段（如script、name、sys_id等，可批量创建）
• 在"要求的角色"中添加x_myrole，无脚本条件
• 保存ACL

步骤2：调整系统属性（按需） #

检查并修改glide.restrict_high_priority_tables属性：

• 导航至系统属性 > 系统 > 安全
• 找到glide.restrict_high_priority_tables，若值为true：
  • 若仅需开放sys_script，可修改glide.db.high_priority.tables属性，将sys_script从列表中移除（列表用逗号分隔）
  • 若需开放所有高优先级表，可将glide.restrict_high_priority_tables设为false（谨慎操作，会降低系统安全性）

步骤3：验证ACL评估 #

重新用测试用户调用API：

GET /api/now/table/sys_script?sysparm_limit=1

同时开启ACL调试日志（系统日志 > 调试日志 > 安全 > ACL），确认字段级ACL也通过评估。

步骤4：扩展权限（若需CRUD） #

如果需要写入/修改权限，重复步骤1，创建字段级的create、write、delete ACL，并确保表级对应操作的ACL也已配置。

内容的提问来源于stack exchange，提问作者Logendran