Security is foundational to Squid's design. As a data integration tool that exports potentially sensitive ServiceNow
data, Squid implements multiple layers of security controls to ensure data is only accessible to authorized users and
systems.
Security Philosophy
Squid's security model is built on three core principles:
Defense in Depth - Multiple independent security layers that must all be satisfiedExplicit Access - Data access requires explicit configuration, not implicit grantsTransparency - Security decisions are visible and auditable
Security Architecture
Squid Security Architecture Overview Squid implements a Defense in Depth security architecture with four independent layers. Every API request must pass through all layers sequentially. Compromise of one layer does not compromise the entire system.
LAYER 1 - AUTHENTICATION: Verifies the user's identity through ServiceNow session authentication. The user must have the x_a46gh_squidx.rest role to access the Squid API. Without this role, all requests are rejected with HTTP 403 Forbidden.
LAYER 2 - CONFIGURATION AUTHORIZATION: Controls which configurations a user can access. Users must have at least one role that is configured on the requested configuration. Predefined configurations require the x_a46gh_squidx.defaultAccess role by default. Custom configurations can specify any ServiceNow roles.
LAYER 3 - DATA ACCESS CONTROLS: Controls what data is returned from configurations. Database views define which columns are available - columns not in the view cannot be accessed. View filters restrict which rows are returned - these are administrator-defined encoded queries that cannot be bypassed by API callers. Optionally, ServiceNow ACLs can provide additional row and field-level security.
LAYER 4 - QUERY VALIDATION: Protects against security circumvention and performance attacks. Forbidden operators (like ^NQ for top-level OR) are always blocked to prevent bypassing view filters. Restricted operators (like CONTAINS, LIKE, javascript:) can be blocked per configuration to prevent performance-degrading queries. Relations access can be restricted to an allowed list per configuration.
RESULT: After passing all four layers, the request proceeds to return a JSON response containing only the data that passed all security checks. API Request Layer 1: Authentication • ServiceNow session authentication • User must have x_a46gh_squidx.rest role Layer 2: Configuration Authorization • User must have at least one role configured on the configuration • Predefined configs require x_a46gh_squidx.defaultAccess Layer 3: Data Access Controls • Database views define available columns • View filters restrict rows • Optional: ServiceNow ACLs Layer 4: Query Validation • Forbidden operators blocked (circumvention prevention) • Restricted operators controlled (performance protection) • Relations access controlled JSON Response DEFENSE IN DEPTH Deep dive into each layer:
Key Security Features
Feature Purpose Documentation Role-Based Access Control who can access the API and specific configurations Authorization View-Based Data Control Define exactly which columns are available for export Data Access Controls View Filters Restrict rows returned per configuration Data Access Controls Forbidden Operators Prevent query-based security circumvention Query Security Restricted Operators Prevent performance attacks Query Security Relations Restriction Control which relations callers can request Authorization Audit Logging Track all access and security events Auditing
ServiceNow ACLs
Why are we talking about security? Doesn't ServiceNow have ACLs?
Squid has a nuanced relationship with ServiceNow ACLs. While ACLs are valuable for interactive UI security, they can
cause significant problems for programmatic data exports due to their silent failure mode.
See: ServiceNow ACLs for a detailed explanation.