Skip to content

VNX-602: Server trusts a client-supplied role or admin flag

Reports server code (Express/Koa, Django/Flask, PHP) that bases an authorisation decision on a role or admin flag taken from the request body, query, URL parameters, headers or unsigned cookies.

Updated 02 Nov 2026Checked against cli@de9b52a
Field Value
Rule ID VNX-602
Severity Medium
SARIF level warning
Kind sast
Languages JavaScript / TypeScript, Python, PHP
CWE CWE-602
CAPEC CAPEC-66
ATT&CK T1190
CWSS vector CWSS:1.0/TI:M/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:M/DI:H/EX:M/EC:N/P:C
Tags authorization client-side-enforcement trust-boundary cwe-602
Source internal/sast/rules/vnx-602.rego

Overview

VNX-602 maps to CWE-602: Client-Side Enforcement of Server-Side Security. When the server checks a value the client sent, the client is the one enforcing the policy, and it can send whatever passes.

The rule reports a comparison, condition or ternary on a request value named for a role or privilege (admin, isAdmin, is_admin, role, user_role, X-User-Role, isAuthenticated, loggedIn, authorized, privileges, accessLevel, userType, permissions, isStaff, superuser), either directly or through a variable assigned from it within the 15 lines above. Sources: req.body, req.query, req.params, req.headers, req.cookies (Express/Koa); request.COOKIES, GET, POST, args, form, cookies, headers, json, values, data (Django/Flask); $_COOKIE, $_GET, $_POST, $_REQUEST, $_SERVER (PHP).

It does not report server-held identity (req.user, req.session, request.user, $_SESSION), signed cookies, the Authorization header, presence checks (isset, comparisons with null/undefined/None), a role written to a new record without a decision, browser UI code that reads a user object, or comments and string literals.

What Gets Flagged

if (req.body.isAdmin) { ... }                                  // FLAGGED
if (req.query.role === 'admin') { ... }                        // FLAGGED
const role = req.cookies.role;
if (role !== 'admin') { return res.status(403).end(); }        // FLAGGED

// NOT FLAGGED
if (req.user && req.user.role === 'admin') { ... }
if (req.session.isAdmin) { ... }
if request.POST.get('is_admin') == "1":    # FLAGGED
if request.COOKIES.get('admin') == "1":    # reported by VNX-784, not VNX-602
if ($_GET['role'] == 'admin') {            // FLAGGED
if ($_COOKIE['role'] == 'admin') {         // reported by VNX-784, not VNX-602

A privilege or login-state cookie compared or tested on the line that reads it, or assigned there to a variable that a condition uses within 15 lines, is a security decision on a cookie: VNX-784 reports that line, so VNX-602 does not report it again. Body, query, URL-parameter and header values, and the decision line of a cookie read a few lines earlier, stay with VNX-602.

Remediation

  1. Take the user’s role from the authenticated server-side session or a verified token, never from a field the client sends.
  2. If a role must travel with the request, sign it (signed cookie, verified JWT claim) and verify the signature before use.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-602
// nosec vnx-602

Or record an ignore rule: vulnetix ignore add --rule vnx-602 --reason "...". See Suppressing findings.

Edit this pageSources: cli/internal/sast/rules/vnx-602.rego, cli/internal/sast/docs/vnx-602.md
esc
↑ ↓ move↵ openSearches in your browser. A key like autonomy.max or a code like threshold_required jumps straight to it.