Accuracy you can audit
614 questions and 147 lessons, each making claims about how attacks and controls work. A wrong claim does not stay on this page: it ends up in your mouth, in a loop, in front of an engineer who has defended that system for real.
Any reference with this much detail will contain errors. Here is how we keep them few, and what you get for catching one we missed.
Send us a claim its source does not support, a control that does not stop what we say it stops, or a standard quoted wrong for its version. Each one we confirm is corrected and credits one day of full access to your account across the whole site. A person checks every report, and there is no cap on how many days you can earn.
If we conclude the original was correct, we send you our reasoning and the source or calculation behind it.
Report an inaccuracy →What we do before anything ships
Every claim has a source
A statement about how an attack works, what a standard requires or what a product does links to its primary source: the paper, the specification, the vendor's own documentation or the advisory. Secondary write-ups are used to find sources, not as them.
Mechanisms before products
Lessons explain why a control works and how it fails before naming any tool that implements it. Products change every quarter; the reason output encoding stops script injection, or a scoped token limits a confused deputy, does not.
Anything that dates says when
Framework revisions, regulatory timelines, product behaviour, incidents and pay figures are written with the month they were checked. A dated claim is one a reader can re-verify; an undated one quietly goes stale.
Measurements keep their uncertainty
Attack success rates, detection rates and benchmark results are reported with the sample size and setup they came from, and with an interval where the sample is small. A rate quoted without its trials is not evidence.
Defensive by design
Attacks are explained at the level of mechanism, enough to design and test a defence. Working payloads, exploit code and step-by-step instructions against real systems are never published, and a contributed question that needs them is rewritten or declined.
Machines check what machines can
Nothing is published until the code compiles, the tests pass and the content checks succeed: every page has its required parts, diagrams are validated against the component that draws them, runnable samples are executed, and generic machine-sounding phrasing is rejected. These checks run before anything reaches the database.
Corrections are dated, not quiet
We log every correction together with what was wrong and how the fix was verified, and the page gets a fresh review date. Mistakes are recorded in the page history instead of being quietly edited away.
What earns the free day
- A claim its cited source does not support
- A control described as stopping an attack it does not stop
- A standard, framework or regulation misquoted for the version or date cited
- A statistic reported without its sample, or computed wrong
- Two pages on this site that contradict each other
- A different valid control for the same risk
- A design choice you would have made differently
- A product or framework change newer than the date the page cites
- Style, or how much detail a topic gets
If one of those design choices looks mistaken rather than merely different, send your evidence. A design point supported by sources is treated as a factual claim and reviewed like any other.
Report an inaccuracy
Sign in before reporting if you want the free day. Reports sent without an account are checked and fixed the same way, with nobody to credit.
Have a question from a real loop rather than a correction? Submit a question instead. That earns a day too, if we publish it.