← All KB Checks
HIGHScriptOnlyCheck

Secure Cookies UI Property

nowisor-secure-cookies··Source on GitHub →

Secure Cookies UI Property

This page describes the nowisor-secure-cookies check from the nowisor Instance Scan Pack v1.0.0. The check audits the glide.ui.secure_cookies system property and produces a finding when the value is not true. This is the UI-layer companion to the transport-level glide.cookies.secure property — the two together close an asymmetry where some session paths may bypass the transport flag.

What this finding means

Your ServiceNow instance is missing the UI-layer enforcement of the secure-cookie contract. The glide.ui.secure_cookies property tells the application server's UI rendering path to treat cookies as security-sensitive — to refuse to set, read, or transmit them outside a secure context — independent of what the browser's Secure flag enforces at the transport level.

The two properties operate at different layers:

When transport-layer Secure is enabled but UI-layer secure_cookies is not, some edge-case session paths — a legacy widget that sets a cookie programmatically without checking the request scheme, a custom UI page that reads a cookie value into a server-side decision — may bypass the transport-flag protection. The two properties together form the defense; either alone is incomplete.

The default on Zurich Patch 6 is true. If your check finding shows otherwise, the property has been disabled (uncommon) or was removed during a long-running customization that left the cluster asymmetric.

Why it matters for your compliance

This is a defense-in-depth control. Regulators don't always cite it by name, but auditors increasingly look at cookie-control symmetry as a marker of mature configuration management.

NIS2 Article 21§2(e) — security in network and information systems acquisition, development, and maintenance. NIS2 expects entities to maintain consistent security configurations across application and transport layers. An asymmetric configuration — transport Secure on, UI secure_cookies off — is a defensible-looking misconfiguration that survives surface-level review but fails a deeper audit. NIS2 expects the deeper review.

ISO 27001 A.8.23 — web filtering. The control covers browser-side and server-side constraints on how session data flows through web layers. The UI-layer property is the server-side complement to the transport flag covered by the same control.

The check does not carry a DORA mapping in the manifest, because the UI-layer property is narrower than the broad DORA Article 9 concerns covered by the transport flag and HttpOnly. That narrowness is intentional — the check is targeted at one specific asymmetry pattern, not the full session-security posture.

Severity 1 (high but not critical) reflects that this property's failure mode is dependent on the existence of another path (custom UI code that doesn't check transport context). On a stock Zurich instance with no custom widgets manipulating cookies, the impact is low. On an instance with significant Service Portal customization, the impact climbs.

The attack path

The attack path is narrow but real. It requires a specific custom-code shape that occurs more often than developers realize.

Step 1 — The asymmetric configuration. Your instance has glide.cookies.secure = true (transport-layer correct) but glide.ui.secure_cookies = false (UI-layer off). The browser enforces HTTPS-only for cookies it has been issued — but the server's UI layer can still set new cookies without checking the request scheme.

Step 2 — The bypass path. A custom widget or UI page sets a cookie programmatically via the platform's UI API. Because UI-layer enforcement is off, the cookie can be set on a response to an HTTP request — the request that should never have been served with cookie material, but is. The platform issues the cookie without the Secure flag (because the request was HTTP); the browser stores it without the flag (because the cookie didn't carry one).

Step 3 — Subsequent leakage. The user's next HTTP request to the same domain attaches the newly issued cookie. The cookie now flows in cleartext for as long as the user remains on HTTP. On the way back to HTTPS, the cookie persists, but the original cleartext exposure window already happened.

This is a real path on customized instances that handle multi-domain traffic, that have UI pages reachable via internal reverse proxies on HTTP, or that have custom integrations that establish session context programmatically. The defense — turning on the UI-layer property — closes the path without affecting normal operations.

How to fix it

The fix is one property change in System Properties:

glide.ui.secure_cookies = true

Apply via System Properties → glide.ui.secure_cookies. The change takes effect immediately for newly initiated UI rendering paths.

For full cluster hygiene, verify the rest of the cookie-protection cluster is consistent:

All four together constitute the complete cookie protection. The check ships a separate finding for each, so a fully-clean scan against this cluster means all four are correctly configured.

After applying the change, review any custom widgets or UI pages that set cookies programmatically. The UI-layer property's enforcement may surface new errors in code that was implicitly relying on lax cookie handling. The right fix is to update the custom code to respect the secure context — not to revert the property.

How to verify the fix

Run this Background Script after applying the property change:

/*
 * Verify nowisor-secure-cookies
 * Read-only, safe for production.
 * Confirms glide.ui.secure_cookies is enforced + reports the full cluster.
 */
(function verifySecureCookies() {
    var SENTINEL = '__NOT_REGISTERED__';
    var prop = 'glide.ui.secure_cookies';
    var value = gs.getProperty(prop, SENTINEL);

    if (value === SENTINEL) {
        gs.print('[FAIL] ' + prop + ' is NOT REGISTERED in sys_properties.');
        gs.print('       Recreate the property with value "true".');
    } else if (value !== 'true') {
        gs.print('[FAIL] ' + prop + ' = "' + value + '" (expected "true").');
        gs.print('       Update via System Properties.');
    } else {
        gs.print('[PASS] ' + prop + ' = true. UI-layer secure-cookie enforcement active.');
    }

    // Cluster symmetry check
    gs.print('');
    gs.print('Cookie cluster symmetry:');
    var cluster = [
        'glide.ui.secure_cookies',
        'glide.cookies.secure',
        'glide.cookies.http_only',
        'glide.cookies.samesite'
    ];
    for (var i = 0; i < cluster.length; i++) {
        gs.print('  ' + cluster[i] + ' = ' + gs.getProperty(cluster[i], SENTINEL));
    }
})();

A fully-clean cluster shows all four properties at their expected values (the first three at true, samesite at lax or stricter). Asymmetries flag here.

What to do next

This finding is one quarter of the cookie-protection cluster. The other three quarters are required for the full defense:

Beyond the cluster, the highest-leverage follow-up is auditing custom widgets and UI pages that set or read cookies. The nowisor advisor product is being built to surface this audit as part of the "session-cluster + custom-code interaction" view, pairing the cookie-protection findings with the LinterCheck output (eval, GlideRecord-vs-Secure) to show which custom code interacts with session material. See the session-protection cluster in the advisor →

Related checks

← All KB Checks