← All KB Checks
CRITICALScriptOnlyCheck

Cookie Secure Flag Enforcement

nowisor-cookie-secure··Source on GitHub →

Cookie Secure Flag Enforcement

This page describes the nowisor-cookie-secure check from the nowisor Instance Scan Pack v1.0.0. The check audits the glide.cookies.secure system property and produces a finding when the value is not true — including when the property has been removed from sys_properties entirely.

What this finding means

Your ServiceNow instance is not setting the Secure flag on session cookies. The system property glide.cookies.secure is either set to a value other than true, or it has been deleted from sys_properties.

The Secure flag is a browser-enforced rule: when a cookie has the flag set, the browser will only transmit it over HTTPS connections. On any HTTP request — including resource fetches, redirects, or accidental HTTP hits — the browser silently omits the cookie. Without the flag, the browser is free to send the cookie over plain HTTP if it happens to make such a request. That's the moment an attacker on the network path can capture it in cleartext.

The default on Zurich Patch 6 is true on HTTPS-served instances. If your check finding shows anything else, one of three things has happened: the property was disabled during a development environment migration to allow HTTP testing, the property was cleared by an integration script that wrote to sys_properties directly, or the instance is genuinely accessible over HTTP at some path (which is itself a finding).

This is the most network-attacker-facing cookie property in the cluster — HttpOnly defends against XSS, Secure defends against the wire.

Why it matters for your compliance

The Secure flag is on every regulator checklist that mentions session cookies, because the failure mode is well-understood and uniquely cheap for an attacker to exploit.

NIS2 Article 21§2(e) — security in network and information systems acquisition, development, and maintenance. Maintaining cookie security attributes is part of secure-development hygiene at the platform level. NIS2 supervisors look at attribute settings during deep-dive reviews of authentication paths; an entity that ships the Secure flag turned off on a production HTTPS endpoint cannot defend that as a documented configuration choice.

ISO 27001 A.8.23 — web filtering. A.8.23's intent extends to browser-layer controls. The Secure flag is the browser's enforcement of "don't send this cookie over an unencrypted transport." Without it, the platform is asking the browser to be lenient about a session token, which is the opposite of the control's intent.

DORA Article 9 — ICT risk management framework. DORA Article 9§4(a) on encryption and Article 9§4(b) on authentication mechanisms both apply. A session cookie that can be transmitted in cleartext is the canonical example of authentication-data exposure under DORA's framing.

This check is severity 1 (critical) because, like HttpOnly, the failure mode is binary: when the Secure flag is off and the instance ever issues an HTTP request that includes the session cookie, the cookie is on the wire. The window can be milliseconds wide, but it is wide enough for a passive network observer to capture.

The attack path

The classical path runs through a network-positioned attacker — a coffeeshop WiFi operator, a compromised corporate proxy, or an ISP-level attacker. The path is short.

Step 1 — Position. The attacker is on the network path between the victim and the ServiceNow instance. This includes shared WiFi (no certificate pinning required if the connection isn't fully HTTPS), corporate proxies, malicious VPN nodes, or BGP-hijack scenarios at the ISP level. The attacker can read traffic in real time but does not have any platform credentials.

Step 2 — Wait for the leak. The browser will follow Secure-flagged cookies only on HTTPS, but without the flag, the browser will attach the cookie to any request matching the cookie's domain — including HTTP requests. The leak point is usually one of: a <link> to an HTTP-served resource (image, font, analytics endpoint), a custom integration that calls back to the instance over HTTP for some reason, or a user who typed http://instance.service-now.com into the URL bar and got a redirect to HTTPS but the redirect itself fired with the cookie attached over HTTP.

Step 3 — Capture. The attacker logs the HTTP request and extracts the cookie value. The session cookie is a string; no decryption is needed.

Step 4 — Replay. The attacker submits the cookie to the instance from their own machine over HTTPS. The platform sees a valid session and authorizes it. The legitimate user notices nothing.

The defense is one property change. With Secure = true, the browser refuses to send the cookie on the HTTP request, the attacker captures nothing, and the protocol-downgrade vector closes.

How to fix it

The fix is one property change in System Properties:

glide.cookies.secure = true

Apply via System Properties → glide.cookies.secure. The change takes effect on the next session establishment.

Pair with these defenses for full transport-layer hardening:

The transport-layer hardening cluster (Secure flag + HSTS + HTTP-disabled) is what regulators want to see when they ask "how do you prevent session cookie exposure?"

How to verify the fix

Run this Background Script after applying the property change:

/*
 * Verify nowisor-cookie-secure
 * Read-only, safe for production.
 * Confirms glide.cookies.secure is enforced + reports the transport-layer cluster.
 */
(function verifyCookieSecure() {
    var SENTINEL = '__NOT_REGISTERED__';
    var prop = 'glide.cookies.secure';
    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. Secure flag enforced on session cookies.');
    }

    // Transport-layer cluster
    gs.print('');
    gs.print('Transport-layer cluster (informational):');
    gs.print('  glide.cookies.http_only = ' + gs.getProperty('glide.cookies.http_only', SENTINEL));
    gs.print('  glide.cookies.samesite = ' + gs.getProperty('glide.cookies.samesite', SENTINEL));
    gs.print('  glide.ui.secure_cookies = ' + gs.getProperty('glide.ui.secure_cookies', SENTINEL));
})();

After enabling the flag, log out of the instance, log back in, and inspect the session cookie in browser devtools. The cookie should have Secure listed in its attribute set.

What to do next

The cookie-protection cluster is small and the components reinforce each other. Review the rest of the cluster:

Beyond the cluster, the highest-leverage follow-up is an audit of all HTTP entry points: any path that responds on HTTP rather than HTTPS, any inbound integration that calls the instance over plain HTTP, any embedded image or script reference in custom UI pages that uses an HTTP URL. The nowisor advisor product is being built to correlate these findings with the cookie cluster so you can see which HTTP paths actually matter for session security. See the session-protection cluster in the advisor →

Related checks

← All KB Checks