How wardn is tested

Unit tests show that code does what its author expected. An authorization library also needs evidence that it does nothing an attacker could exploit, including things its author didn’t think of. wardn is tested in layers.

The layers

Layer	What it proves
A test per rule and per threat	Each evaluation rule, and each threat in the threat model, has a named test.
Reference implementation	A second, deliberately naive implementation of the rules is compared with the engine on about 130,000 random checks per run.
Escalation-guard attack	In 300 random worlds, an actor with random roles tries random assignments. Every one allowed is independently confirmed not to escalate.
Cache staleness	Two instances share a store and a cache; after random changes, 72,000 answers are checked against the reference.
Fault injection	Every write is repeated with each database and cache call failing in turn, including inside SQL transactions. No failure may leave access that neither the old nor the intended state grants, and no role may be left half-written.
Mutation testing	58 deliberate breaks of specific security rules. The test suite must catch every one, so no rule is unprotected.
Fuzzing	8 targets (policies, IDs, URLs, role names, role specs, cursors, cache contents, Check) ran over 14 million inputs. A weekly campaign continues.
Real databases	PostgreSQL, MySQL, MariaDB, SQLite and MongoDB in every CI run, through the same 25-check store conformance suite. Redis runs the cache conformance suite.
Independent review	A reviewer with only the code and design, not the author’s reasoning, set out to break wardn.

What the hardening found

These layers found real problems, which is the point. All were fixed, and each fix is held in place by a regression test and a mutation test.

Finding	Found by
The escalation guard ignored a role’s denies, so a manager could lift a suspension or lock out a superior	Independent review
A forged cache entry could grant super-admin	Fuzzing
A partly failed cascade delete could leave a deleted role granting from the cache	Independent review
A far-future start date overflowed into the past in database stores	Independent review
MySQL’s default comparison treats O1 and o1 as equal	Conformance suite

The full report, including accepted risks and a brief for later reviewers, is docs/SECURITY_REVIEW.md.

Run it yourself

make check                  # every gate: lint, security lint, tests, vulnerabilities, dependencies
make integration            # every module against real databases in Docker
make mutation               # break each security rule; confirm a test catches it
make fuzz FUZZTIME=5m       # run every fuzz target