← All KB Checks
CRITICALScriptOnlyCheck

CSRF Token Enforcement

nowisor-csrf-token-enforcement··Source on GitHub →

CSRF Token Enforcement

This page describes the nowisor-csrf-token-enforcement check from the nowisor Instance Scan Pack v1.0.0. The check audits the glide.security.use_csrf_token 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 validating CSRF tokens on state-changing requests. The system property glide.security.use_csrf_token is either set to a value other than true, or it has been deleted from sys_properties so the platform falls back to undocumented runtime behavior.

CSRF (Cross-Site Request Forgery) tokens are the platform's mechanism for proving that a state-changing request — inserting a record, updating a role grant, calling a script — originated from a page your platform rendered, not from a malicious page that hijacked the user's authenticated session. When token enforcement is off, the platform cannot tell the difference between a legitimate admin clicking a button and a malicious third-party site silently submitting forged requests using the admin's cookies.

The default value on Zurich Patch 6 is true. If your check finding shows anything else, the property has been changed deliberately — either by an integration that struggled with CSRF tokens (most common), or by a debugging session that was never cleaned up.

Why it matters for your compliance

CSRF token enforcement is one of the platform-hardening controls that European regulators expect every ServiceNow deployment to maintain as part of routine information-system security posture.

NIS2 Article 21§2(a) — risk analysis and information system security policies. CSRF defenses are part of the documented security baseline; disabling them without a compensating control is a finding an auditor will document.

ISO 27001 A.5.15 — access control. CSRF protection is the implementation layer that enforces "the authenticated principal of a session must be the principal who initiated each request." Without it, every other access control on the instance is conditional.

DORA Article 9 — ICT risk management framework. Financial entities under DORA are expected to maintain defense-in-depth at the application layer. CSRF token enforcement is a foundational layer; its absence is not defensible as a "low-risk omission."

In all three frameworks, the question is not whether you can show CSRF protection is enabled — it's whether you can demonstrate, with evidence pulled at audit time, that it remained enabled across the assessment period.

The attack path

CSRF without strict validation gives an attacker the most efficient path to instance takeover in the platform: a single phishing click. The mechanics are well-understood but worth restating in the customer context.

Step 1 — Payload. Attacker crafts a hidden form (or, on older releases, a hidden image) that submits a request to the target instance:

<form action="https://yourinstance.service-now.com/sys_user_has_role.do"
      method="POST" style="display:none">
  <input name="user" value="ATTACKER_USER_SYSID">
  <input name="role" value="ADMIN_ROLE_SYSID">
</form>
<script>document.forms[0].submit();</script>

(On modern releases — Washington and later — GET-based variants are increasingly blocked, so the form-POST shape is the realistic vector.)

Step 2 — Delivery. Payload is hosted on a controlled site, or embedded in a phishing email rendered by the victim's browser. The victim must be authenticated to ServiceNow in the same browser context.

Step 3 — Execution. Browser submits the form with the victim's session cookie attached. Without CSRF token validation, ServiceNow processes the request as the victim's legitimate action.

Step 4 — Result. Attacker's account receives the admin role. Full platform compromise from a single click.

The cost of this attack against a CSRF-disabled instance is one phishing email. The cost against an instance with CSRF strict validation is materially higher, because the attacker now needs to defeat token validation — which typically requires a second platform vulnerability.

How to fix it

The fix is one property change in System Properties:

glide.security.use_csrf_token = true

Apply via System Properties → glide.security.use_csrf_token (or sys_properties.list?sysparm_query=name=glide.security.use_csrf_token). The change takes effect immediately.

If you have integrations that started failing when you set this — a common cause of the property being disabled in the first place — the right fix is to update those integrations to use OAuth or API keys instead of session-cookie authentication. Session cookies were never the intended authentication mechanism for service-to-service traffic, and routing integrations through OAuth restores compliance posture without breaking functionality.

If you have a custom UI that submits forms without CSRF tokens, regenerate the form using the platform's standard UI Form macro, which injects the token automatically.

Pair this fix with glide.security.csrf.strict.validation.mode = true for defense in depth. The strict-mode flag is true by default on Zurich Patch 6, but verify it on your instance — if your team had reason to disable use_csrf_token, they may have disabled strict mode in the same session.

How to verify the fix

Run this Background Script after applying the property change. It reads the live value and reports either compliance or the specific anomaly:

/*
 * Verify nowisor-csrf-token-enforcement
 * Read-only, safe for production.
 * Confirms glide.security.use_csrf_token is enforced.
 */
(function verifyCsrf() {
    var SENTINEL = '__NOT_REGISTERED__';
    var prop = 'glide.security.use_csrf_token';
    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. CSRF token enforcement active.');
    }

    // Companion check — strict validation mode
    var strict = gs.getProperty('glide.security.csrf.strict.validation.mode', SENTINEL);
    gs.print('');
    gs.print('Companion property glide.security.csrf.strict.validation.mode = ' + strict);
    gs.print('Recommended: true (default on Zurich Patch 6)');
})();

Re-run the nowisor scan after applying the fix. The check should no longer produce a finding.

What to do next

The CSRF finding rarely appears in isolation. The same operational pattern that disabled CSRF — a struggling integration or an unfinished debugging session — frequently weakens related controls. Review these companion checks in your scan report:

For audit evidence, the nowisor advisor product is being built to package each scan finding with the regulatory mapping, attack-path narrative, and remediation status into an export your compliance team can attach directly to the relevant control evidence. The agent pack produces the findings; the advisor produces the evidence package. Learn more at nowisor.com.

Related checks

← All KB Checks