Rule
unguarded-sensitive-state-write
A successful path writes policy-protected state without the configured preceding guard.
Specimen 42 of 96 · Policy-dependent rules
- Severity
- high
- Confidence
- medium
- Maturity
- experimental
- Selection
- Audit; needs policy
- Policy intent
- required
- Release
- v0.1.1
- Engine facts used
successful-pathsstate-writesguard-callsauthorization-policy
Selection and scope#
Selected by the default audit profile, but it stays dormant until policies in nightshade.json declares the matching application intent. Selecting it alone does not supply that intent.
./.nightshade/node_modules/.bin/nightshade ./contracts --detectors unguarded-sensitive-state-write
./.nightshade/node_modules/.bin/nightshade detector show unguarded-sensitive-state-writeThe first command runs only this rule; --detectors takes a comma-separated list. The second prints the rule's metadata from your installed version.
Severity is review priority. It does not express exploitability or impact. Confidence is detector metadata, not a probability. All built-in rules are experimental.
Compiler scope: the engine supports the pinned profiles 0.28.0, 0.29.0, 0.30.0, 0.31.1, 0.33.0-rc.2, 0.34.0, 0.35.0-rc.1 and 0.35.0, with ZKIR2 by default. Support for this rule can be narrower; the rule documentation below states any narrower scope.
Corpus checks#
Synthetic corpus checks for this rule in the 0.1.1 proof run. A check counts only with compiler acceptance and complete analysis.
| Positive detected | Corrected quiet | Lookalike quiet | Other negative quiet | Incomplete |
|---|---|---|---|---|
| 3/3 | 3/3 | 2/2 | 0/0 | 0 |
No deviations were recorded for this rule.
These are behavior checks on synthetic fixtures, not a precision or recall estimate. See evaluation.
Rule documentation#
From docs/detectors/unguarded-sensitive-state-write.md at v0.1.1.
Availability: policy-required; selected by default, but needs policies.authorization. Severity high, confidence medium.
Reports a successful write to policy-protected ledger state without its required preceding successful void guard call. A write to a state dependency of that guard invalidates the earlier check. The configured requirement also applies to constructor writes.
Example and review scenario#
The compiler-qualified owned fixture has publish call a storage helper without its configured guard:
{ "authorization": [{ "state": "published", "guard": "authorize" }] }Place this object under policies in the configuration. The correction calls authorize() before store(value). This supports review of a documented requirement shared by several entrypoints or helper paths.
Recommendation: use a reviewed, constraining circuit returning [] before every protected mutation, and recheck after changing state that the guard reads.
False positives and limitations#
The rule trusts the policy's guard meaning; it does not audit the guard or infer privilege from its name. A different check or a later atomic check can satisfy business intent while still violating the configured preceding-call requirement. An overbroad policy may therefore flag intentional behavior. A helper returning a witness Boolean alone is not the required successful void guard call. Abstract paths do not prove concrete feasibility or cross-transaction authorization. Unknown effects and exhausted budgets remain incomplete.
Source examples#
These short regression examples are included here for installed-package readers. Rule-specific policy requirements and limits above still apply.
Example 1#
Fixture (source: tests/corpus/vulnerable/required-guard.compact).
pragma language_version >= 0.26.0;
export ledger allowed: Boolean;
export ledger published: Field;
circuit authorize(): [] { assert(allowed, "permission required"); }
circuit store(value: Field): [] { published = disclose(value); }
export circuit publish(value: Field): [] {
store(value);
}Example 2#
Correction (source: tests/corpus/safe/required-guard.compact).
pragma language_version >= 0.26.0;
export ledger allowed: Boolean;
export ledger published: Field;
circuit authorize(): [] { assert(allowed, "permission required"); }
circuit store(value: Field): [] { published = disclose(value); }
export circuit publish(value: Field): [] {
authorize();
store(value);
}Suppress a match#
If a match is intentional, suppress it on the line before with the exact rule ID and a reason of at least eight characters:
// nightshade-disable-next-line unguarded-sensitive-state-write -- Reason this match is intentionalDiagnostics cannot be suppressed, and an unmatched directive for a selected rule makes analysis incomplete. See configuration for fingerprint suppressions and baselines.