OWASP Cheat Sheet Series language review process
The OWASP Cheat Sheet Series uses a language and editorial reviewer for pull requests that checks US English correctness, grammar, clarity for non-native readers, and the project's structural and style conventions. The review focuses on grammar and spelling errors, US English usage, clarity for non-native readers, acronym definition, tone and concision, and structure conventions. Linters (npm run lint-markdown and npm run lint-terminology) are run to catch concrete issues, then manual review catches what linters miss. Review findings are reported with severity levels: MAJOR, MINOR, or NIT, with verdict of PASS, CONCERNS, or BLOCK.
Cheat sheet structure conventions
OWASP Cheat Sheet Series structure conventions specify: H1 must be the cheat sheet title; opening section is named 'Introduction'; blank lines must appear after headings; no manually added table of contents; lists use hyphen (-) format. A 'References' section is conventional but optional — about half the series cites inline instead. Typical cheat sheets have 3–6 H2 sections, though more is acceptable for broad topics.
Cheat sheet review scope boundaries
Language and editorial review of OWASP Cheat Sheet changes should only flag text touched by the pull request unless a structural problem affects the whole file. Mechanical markdownlint and textlint rules run in CI, so manual review focuses on what linters miss. BLOCK verdict is used only when language is so poor it impairs comprehension or correctness; CONCERNS for multiple real errors; PASS for clean, clear prose with at most trivial nits.
cheatsheet-link-auditor tool purpose
The cheatsheet-link-auditor is a fact-checking editor tool designed to audit links and sources added or changed in OWASP Cheat Sheet pull requests. It goes beyond checking if links work to judge whether each cited page is authoritative and actually supports the specific claim it is attached to. The tool flags hallucinated, irrelevant, or weak citations, which are identified as the number-one reason these PRs get reverted.
Link audit scope for added or modified changes
The link auditor only audits links that are added or modified in a diff, not the entire file unless explicitly asked. Audited link types include external URLs cited inline as [text](https://...) and internal links to other cheat sheets or sections that must resolve to a file or anchor existing in the repository.
Link audit checklist for every added or changed link
For each added or changed link, perform five checks: (1) Reachability & redirects — fetch it and determine if it resolves to real, relevant content or returns 404, a parked/SEO page, a login wall, or an unrelated redirect; note if it requires a spoofed User-Agent. (2) Supports the claim — read the page and verify it substantiates the exact sentence or recommendation it cites; a real on-topic link that does not back the claim is still a failure. (3) Authority & quality — authoritative sources include RFCs, NIST, OWASP, official vendor/project documentation, MDN, reputable tool docs, and canonical source repositories; flag genuinely weak sources such as SEO/marketing content farms, low-quality blog reposts like Medium rehashes, random forum posts when a primary source exists, or a vendor's marketing blog supporting a vendor-neutral claim. (4) Currency — determine if the page is current or stale/archived/superseded. (5) Internal links — confirm the target file exists in cheatsheets/ and the anchor matches a real heading by verifying with Glob, Grep, or Read.
Link audit verdict severity mapping
Link audit verdicts map to severity as follows: BROKEN, WRONG-PAGE, or UNSUPPORTED = BLOCK; LOW-AUTHORITY or STALE = CONCERNS; All OK = PASS.
OWASP Cheat Sheet audience is developers, not security experts
The audience for every cheat sheet in the OWASP Cheat Sheet Series is developers, not security experts. Content must be accurate, practical, concise, and opinionated. The series prefers good advice a developer can follow over best advice they cannot.
Sources in OWASP cheat sheets must be real, read, and supportive
Contributors must have actually fetched and read each source and confirmed it supports the specific claim. Never invent or guess a URL. Fabricated citations, links that 404 or redirect to a homepage, and links to a page that does not actually support the claim are grounds for PR rejection. Always link to the specific page or section that supports the claim, not an index or landing page. Do not link to cheat sheet pages or anchors that do not exist.
OWASP cheat sheet citation requirements
Every new H2 section must contain at least one inline citation [text](https://...). Beyond that, any novel, surprising, parameter-specific, or contestable claim needs its own source. Well-established common practice does not need a citation on every sentence. Sources may be inline or collected in a References section. Internal cross-links to other cheat sheets are encouraged but do not satisfy the citation gate, which only counts https:// links.
OWASP cheat sheets must pair threats with concrete countermeasures
Claims must be correct and within the security threat model. Pair every threat with a concrete countermeasure, and state explicitly what a control does and does not protect against. Do not drag in attacks outside the topic's threat model without a caveat. Add only guidance that is genuinely a security control or risk.
OWASP cheat sheet PR scope limits
A PR modifies a single cheat sheet or a small, clearly-coordinated set. CI enforces a hard limit of 3 cheat sheets and 1500 net added lines without a linked tracking issue. Work from a clean branch off master, one topic per branch. Never open two PRs from the same branch. A new or substantially updated cheat sheet requires an approved issue first.
OWASP cheat sheets use linking to avoid duplication
Before adding a section, check whether it already exists in this or another cheat sheet. If the topic is covered elsewhere, link to it instead of restating it. Coordinated multi-sheet families that cross-link in a hub-and-spoke pattern are intentional and correct. Confirm the content belongs in the cheat sheet being edited.
OWASP cheat sheets prefer architecture over code for general topics
For general topics, prefer architectural patterns, design principles, and security decisions over language-specific code. Language-specific, injection/payload, parameterization, and hardening sheets are expected to be code-dense. When code is illustrative, keep it short and language-tag fences where practical.
OWASP cheat sheets must be concise and opinionated
Be concise and opinionated. Cut generic filler, verbose preambles, restated obvious background, and generic intros. Recommend a specific approach; do not enumerate every option. Content that reads like generic AI output will be rejected.
AI usage must be declared in OWASP cheat sheet PRs
Any PR whose content was generated or materially assisted by AI must disclose it in the PR description: tool name (Claude, Copilot, Cursor, Codex), version if known, and the prompt used. This applies to all AI tools. Failure to disclose can get the contribution deleted.
OWASP cheat sheet format requirements
Use US English. Keep language simple for non-native readers. Define non-obvious acronyms on first use. Use Markdown only, avoiding raw HTML except details/summary. Lists use hyphens. Bold uses double asterisks. Quotes use angle brackets. Structure: H1 name, then typically Introduction as first H2, then main H2 sections, then optional References. Blank line after every heading. Filenames use letters/numbers/hyphens/underscores only, ending _Cheat_Sheet.md. Assets go in assets/ as PNG files.
OWASP cheat sheets enforce local checks before PRs
Contributors must run npm run lint-markdown (markdownlint), npm run lint-terminology (textlint for US English/terminology), and npm run link-check (detects dead links) before proposing changes. CI enforces: PR scope (pr-scope-check), citation density (citation-check: every new H2 must contain at least one inline https:// citation), and link check. These catch mechanical problems but do not judge whether a source actually supports its claim or whether advice is correct.
OWASP cheat sheet target audience and priorities
OWASP cheat sheets are written for developers who build software daily but lack deep security knowledge. They prioritize practical, actionable advice over theoretical discussion. Content must be concise, opinionated (recommending specific approaches rather than listing options), and focused on what developers can implement today.
Architecture-first approach over language-specific code samples
OWASP cheat sheets should prioritize architectural patterns, design principles, and security decisions over language-specific code samples. Architectural guidance applies across languages and frameworks and is more durable. Code examples should only be used when they illustrate a concept difficult to explain in prose, such as specific API call patterns or configuration syntax. When code is included, keep it short and clearly illustrative rather than production-ready.
OWASP cheat sheet structure requirements
Every OWASP cheat sheet follows this structure: a title, an introduction section (2-4 sentences covering what the sheet addresses and why it matters), 3-6 main sections organized by distinct aspects of the topic (with H3 subsections for complex areas), and a references section linking to authoritative external resources. Content must stay focused on one topic; related topics should have their own cheat sheets.
Avoid abstract security recommendations
OWASP cheat sheets must avoid abstract or vague guidance like 'validate all input'. Instead, describe the specific validation strategy and what it protects against. Recommendations must be concrete, feasible to implement, and include the 'why' to help developers prioritize and remember them.
When to use tables in OWASP cheat sheets
Use tables to show secure versus insecure approaches side by side, making comparisons clear and actionable. Tables are an effective format for presenting alternative methods and their implications.
OWASP Cheat Sheet Series index of 92 sheets
The OWASP Cheat Sheet Series contains 92 cheat sheets covering application security topics organized alphabetically from Access Control to XS Leaks. Each sheet provides concrete controls, settings, and algorithms for specific security domains.
ASVS 4.0 index structure by verification domain
The ASVS 4.0 index maps 14 verification domains to relevant cheat sheets. V1 covers Architecture, Design and Threat Modeling. V2 covers Authentication. V3 covers Session Management. V4 covers Access Control. V5 covers Validation, Sanitization and Encoding. V6 covers Stored Cryptography. V7 covers Error Handling and Logging. V8 covers Data Protection. V9 covers Communications. V10 covers Malicious Code. V11 covers Business Logic. V12 covers File and Resources. V13 covers API and Web Service. V14 covers Configuration.
V5.3 Output encoding and Injection Prevention references XXE Prevention Cheat Sheet
For XXE prevention covered under V5.3 Output encoding and Injection Prevention Requirements, OWASP references the XXE Prevention Cheat Sheet.
Authoritative sources for OWASP cheat sheets
Use authoritative sources for citations in OWASP cheat sheets. Valid sources include:
- RFCs
- NIST
- OWASP
- Official vendor or project documentation
- MDN (Mozilla Developer Network)
- Reputable tool documentation
- Canonical source repositories (e.g., GitHub)
- Peer-reviewed research
These sources should not be flagged as low-authority. When multiple sources are available, prefer the most authoritative source and avoid SEO/marketing content farms. A solid project documentation page, MDN page, or canonical repository is a valid citation.