--- sourceDocument: Brazil Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Query ACLs # Query ACLs {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Query ACLs Query ACLs in ServiceNow provide granular access control by explicitly defining which users can perform specific query operations on data. They enhance security by restricting or enabling query capabilities based on user roles and data sensitivity, particularly protecting against blind query attacks that attempt to extract information without direct visibility of values. Show full answer Show less ## When to Use Query ACLs Implement query ACLs whenever columns contain sensitive data or when partial or conditional access to data rows and columns is required but not enforced by data filters. This is especially important when some users should access only certain rows or columns and not others. Examples include: * **Payroll Queries:** Preventing users from performing range queries on salary data to restrict access beyond their own record. * **HR Profiles:** Allowing users to see their own Social Security Number (SSN) but preventing querying SSNs of others. ## Query ACL Behavior and Operations Query ACLs operate using two types of operations to control query access: * **querymatch:** Supports "safe" operators like EQUALS, NOTEQUALS, IN, NOTIN, SAMEAS, ISNULL, ISNOTNULL, etc. These operators fetch specific records without returning unintended data. Passing a querymatch ACL allows the user to submit such precise queries; failing blocks these queries. * **queryrange:** Includes operators like STARTSWITH, CONTAINS, \>=, \<=, which allow querying over ranges or subsets of records and thus can expose more data. Passing a queryrange ACL permits range queries and unrestricted sorting; failing blocks range queries and restricts sorting by the column. **Important:** If no query ACL is defined on a column, the system defaults to a star.star ACL that delegates to standard read access. Defined query ACLs override this default behavior, enforcing stricter query control. Query ACLs allow you to define more granular access control by explicitly defining who can query the data. ## What is a query ACL {#query-acl-rule__section_ctb_1yl_zbc} A query ACLs have their operation set to either `query_range` or `query_match`. Query ACLs allow for more specific control of user queries, restricting or enabling access based on their setup. Query ACLs are powerful tools against blind query attacks, where an attacker blindly queries the data to extract information from results, even when they can't see the values. ## When to use a query ACL {#query-acl-rule__section_pn2_yf5_pcc} Wherever a column contains sensitive values, and allows partial/conditional access to data a query ACL should be considered and implemented as necessary based on the sensitivity of the data. Wherever there is a partial/conditional access to rows and their columns in tables, especially where that access is not enforced by data filters, query ACLs should be implemented as necessary based on the sensitivity of the data. Note: Consider query ACLs when some users have access to some rows or columns and not others . ## Payroll query control {#query-acl-rule__example_ngj_rh5_pcc} I can see one row in payroll table with my salary, but there is no reason for me to be able to issue range queries to query users with a salary contained within 2 boundaries. A `query_range` ACL on salary would prevent me from issuing that query. ## HR query control {#query-acl-rule__example_p1g_vh5_pcc} I can see all hr_profiles, but can only see SSN for myself. I have no business querying SSN, and query ACLs should prevent me from running queries against SSN of other hr profiles to try to extract SSN mappings. ## Query ACL behavior {#query-acl-rule__section_xbm_dg5_pcc} Query ACLs use `query_match` and `query_range` operations for secure and granular table querying behavior. Their behaviors are described below: `query_match` : `query_match` is composed of: EQUALS, NOT_EQUALS, IN, NOT_IN, SAMEAS, NSAMEAS, ANYTHING, ISEMPTYSTRING, ISEMPTY, ISNOTEMPTY, ISNULL, ISNOTNULL. `query_match` is made of the "safe operators", in a sense that they are built to fetch specific record(s), and can't be exploited to return others. {#query-acl-rule__table_c3k_1zl_zbc__entry__2} | Evaluation outcome | Result | |-|-| | Pass | User can submit match queries | | Fail | User will not be able to submit match queries: * EQUALS * NOT_EQUALS * IN * NOT_IN * SAMEAS * NSAMEAS * ANYTHING * ISEMPTYSTRING * ISEMPTY * ISNOTEMPTY * ISNULL * ISNOTNULL {#query-acl-rule__ul_un1_335_pcc} | [ ] {#query-acl-rule__table_c3k_1zl_zbc} `query_range` : `query_range` is composed of all the others (STARTS_WITH, CONTAINS, \>=, \<= etc) which are more dangerous as they allow users to query for more records by adjusting the boundary values. {#query-acl-rule__table_jnn_5pl_zbc__entry__2} | Evaluation outcome | Result | |-|-| | Pass | User can submit range queries and sorting is unrestricted | | Fail | The user will not be able to submit range queries with (STARTS_WITH, CONTAINS, \>=, \<=, etc. Sorting by column is restricted | [ ] {#query-acl-rule__table_jnn_5pl_zbc} Important: Query ACLs (both query_match and query_range) default to a star.star ACL that delegates to read access. This means, where ACLs are enforced on queries, if no query ACL was created then read access to the column is evaluated ; if query ACLs are defined then they override the default behavior.