# unguarded-sensitive-state-write

> A successful path writes policy-protected state without the configured preceding guard.

Canonical: https://nightshade.dicksonwu.xyz/rules/unguarded-sensitive-state-write.html
Release: Nightshade 0.1.1 (v0.1.1)

| Field | Value |
| --- | --- |
| Rule ID | `unguarded-sensitive-state-write` |
| Severity | high |
| Confidence | medium |
| Maturity | experimental |
| Selection | Audit; needs policy |
| Policy intent | required |
| Default enabled | yes |
| Category | Policy-dependent rules |
| Engine facts used | successful-paths, state-writes, guard-calls, authorization-policy |
| Release | v0.1.1 |

## 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.

```sh
./.nightshade/node_modules/.bin/nightshade ./contracts --detectors unguarded-sensitive-state-write
./.nightshade/node_modules/.bin/nightshade detector show unguarded-sensitive-state-write
```

The 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](https://nightshade.dicksonwu.xyz/evaluation.md#synthetic-corpus).

## Rule documentation

From https://github.com/DicksonWu654/nightshade/blob/v0.1.1/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](#example-1)
has `publish` call a storage helper without its configured guard:

```json
{ "authorization": [{ "state": "published", "guard": "authorize" }] }
```

Place this object under `policies` in the [configuration](https://github.com/DicksonWu654/nightshade/blob/v0.1.1/docs/configuration.md).
The [correction](#example-2) 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`).

```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`).

```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:

```compact
// nightshade-disable-next-line unguarded-sensitive-state-write -- Reason this match is intentional
```

Diagnostics cannot be suppressed, and an unmatched directive for a selected rule makes analysis incomplete. See [configuration](https://nightshade.dicksonwu.xyz/configuration.md#suppress-an-intentional-match) for fingerprint suppressions and baselines.

## References

- [Rule source document at v0.1.1](https://github.com/DicksonWu654/nightshade/blob/v0.1.1/docs/detectors/unguarded-sensitive-state-write.md)
- [Catalog entry in rules.json](https://nightshade.dicksonwu.xyz/rules.json)
- [All rules](https://nightshade.dicksonwu.xyz/rules.md#policy-dependent-rules)
- [Limitations](https://nightshade.dicksonwu.xyz/limitations.md)