LEARN. PRACTICE. GROW.Concept and mechanism
A secure application distinguishes menu access, code execution, cross-scope access, and data access. Hiding a module does not prevent someone from trying a record URL. An ACL considers the operation and resource; table access does not automatically resolve every field’s access. Rules can combine roles, conditions, and scripts. Identify the applicable rule and test with a representative identity, avoiding conclusions based only on admin. Scoped GlideSystem hasRole returns true for an administrator, so that test can conceal a missing expected role for an operator. In current documentation, an applicable failing Deny-Unless can deny access despite a favorable Allow-If. Record negative tests too: an unauthorized user should remain blocked.
Guided application
A Script Include reuses server logic. Making it client callable creates another access surface: inspect execution ACL, inputs, returned data, and record authorization. A role sent by the browser is not evidence of the effective identity. Documentation recommends GlideRecordSecure for operations that must respect data access, but this does not remove business rules and request validation. Protection policy protects code as intellectual property; it is not the data ACL for records queried by that code. Similarly, enabling web services on a table does not grant permissions to the integration user. During an exposure incident, limit the response to its necessary contract, preserve evidence, and correct server authorization. Never use a broad administrative role to demonstrate that the minimum access design is correct.
A client-callable method should authorize the caller before returning confidential fields.
Common pitfalls
Menu treated as security; protected code treated as protected data; admin-only testing.
Related topics: Needs, data, and design · Scope, modules, and dependencies · Forms and client/server logic
Verify each access boundary and the observed result.
Reference: Script Includes · CAD blueprint January 2026