Basic Auth Role Without WSAO

This page describes the nowisor-basic-auth-role-without-wsao check (new in pack v1.1.0). It flags active accounts that hold the Basic Auth API allow-list role but are not web-service-access-only — and escalates to Critical when the account is also privileged.

What this finding means

The snc_basic_auth_api_access role (read from glide.authenticate.basic_auth.allowed_roles, which may list more than one role) keeps an account's Basic Auth API access working after enforcement begins. It is meant as a temporary exception for service accounts. This check fires when an active account holds that role but web_service_access_only = false — meaning it can also log into the UI. That account can authenticate to the UI and to APIs with single-factor Basic Auth: the documented temporary path turned into a standing MFA bypass on a human-loginable account.

When the same account also holds admin or security_admin, the finding is escalated to Critical — a single-factor Basic Auth path straight to administrative capability. mid_server accounts are excluded (a legitimate Basic Auth path).

Why it matters

This is the most direct MFA bypass the Basic Auth allow-list can produce: a real person (or a human-loginable account) keeping single-factor API access permanently. On a privileged account it is a platform-takeover path that no amount of UI-side MFA closes, because the API path never asks for the second factor.

How to remediate

For each flagged account: if it is an integration identity, set web_service_access_only = true (WSAO) so it cannot log into the UI; if it is a human, migrate API use to OAuth and remove the role. Treat snc_basic_auth_api_access as a time-boxed exception, not a permanent grant. Remediate privileged accounts (admin / security_admin) first.

Verified against ServiceNow Zurich Patch 6 (dev265147), 2026-06-11.