ServiceNow application security is strongest when developers treat authorization as part of application architecture rather than a final hardening step. A scoped application can protect its tables and files from other applications, ACLs can control which users may read or change records, and roles can express functional capabilities. For candidates pursuing the ServiceNow Certified Application Developer<\/a> credential, secure development therefore means designing trust boundaries before writing business logic.<\/p>\n The platform provides several layers that can overlap: application scope, table application-access settings, cross-scope privileges, ACLs, role inheritance, Script Include access, and authentication for external integrations. Developers need to understand what each layer protects so they do not compensate for a missing boundary with overly broad code. The wider ServiceNow certification<\/a> ecosystem depends on the same principle because custom applications often interact with shared platform data and ITSM processes.<\/p>\n ServiceNow recommends private application scope for most custom business applications. Scope gives the application a namespace and restricts what other applications can do with its artifacts by default. That reduces accidental interference and supports cleaner ownership. Global scope is appropriate only when the application genuinely needs platform-wide behavior that cannot be expressed safely through scoped interfaces.<\/p>\n Choosing scope is an architectural decision because the internal names of scoped artifacts are tied to it. Developers should make that choice before building tables and logic. The security concepts in secure application design<\/a> apply directly: isolate components by default, expose only the interfaces other components need, and avoid expanding trust merely because it is convenient during development.<\/p>\n Private scope also improves the review boundary. A security reviewer can identify which tables and scripts belong to the application and evaluate its external dependencies more systematically. In a large global customization layer, ownership is harder to determine and unrelated scripts may share names or assumptions. Scoped ownership does not guarantee security, but it makes the application surface small enough to reason about, which is a major advantage during code review and platform upgrades.<\/p>\n An application role should answer what capability the holder gains. \u201cRequest approver\u201d or \u201capplication administrator\u201d is clearer than a role copied from an organizational title that may change over time. Roles can be assigned through groups and can contain other roles, so developers should understand inheritance before granting powerful access.<\/p>\n Keep application roles narrow. If one role can view sensitive records, change configuration, and administer users, it becomes hard to assign safely. Separate administration from normal fulfillment where practical. The ServiceNow CSA<\/a> foundation is relevant because users, groups, and roles are platform constructs that custom applications should reuse rather than reinvent.<\/p>\n Role naming should avoid implying more trust than the capability needs. A role called app_admin may gradually accumulate unrelated powers because developers assume administrators can do everything. Prefer separate configuration, approval, support, and data-management roles when those responsibilities differ. This gives customers a way to delegate administration safely and reduces the pressure to grant the system admin role for routine application management.<\/p>\n Forms and UI policies are not authorization controls. A field hidden in the interface can still be queried or changed through another surface if the user has permission. Record ACLs should enforce the actual security requirement at the table and field levels. Conditions and roles are easier to review than complex scripts, so use scripted ACL logic only when declarative rules cannot express the requirement.<\/p>\n Test ACLs with users who do not have admin privileges. Administrators can pass checks that ordinary users fail, making privileged testing misleading. Include negative tests that prove the restricted persona cannot read, create, update, or delete what it should not. Secure development is complete only when the denial path is verified as deliberately as the allowed path.<\/p>\n ACL tests should include direct API or list access where relevant, not only the main form. Attackers and integrations do not have to use the interface your developers designed. If a field is sensitive, verify that the server denies unauthorized reads even when the request bypasses the form. This is why security belongs at the data boundary: user-interface behavior can change without weakening the core authorization decision.<\/p>\n Scoped applications sometimes need to call resources in another application or allow another scope to use a table or Script Include. Cross-scope access should be treated like an API contract. Expose the narrow resource and action required rather than enabling broad access to make an error disappear. The \u201cAccessible from\u201d and application-access settings are security architecture, not troubleshooting shortcuts.<\/p>\n When a cross-scope request is denied, investigate whether the calling application truly needs the operation. If it does, document the relationship and allow only the necessary action. If it does not, redesign the dependency. This keeps application boundaries understandable and prevents a growing network of implicit trust between unrelated customizations.<\/p>\n Cross-scope interfaces should also have stability expectations. If another application depends on a Script Include method or table field, changing that interface can break consumers. Document supported contracts and avoid exposing internal helper methods unnecessarily. Security and maintainability reinforce each other here: a narrow public surface is easier to protect and easier to keep compatible across application versions than a large set of broadly accessible internals.<\/p>\n Developers often expose server-side logic to clients through GlideAjax-enabled Script Includes or other callable resources. Anything callable from the client should assume that input can be manipulated. Validate parameters on the server, enforce data access independently of the client, and protect callable resources with appropriate ACLs or role checks.<\/p>\nStart with a private scope unless the design requires global behavior<\/h3>\n
Use roles to represent capabilities, not job titles alone<\/h3>\n
ACLs should protect data at the table and field boundary<\/h3>\n
Cross-scope access should be an explicit interface<\/h3>\n
Client-callable server logic needs extra protection<\/h3>\n