OWASP secure coding

Why this exists

Most breaches come from a short list of mistakes that are well understood and well documented: injection, broken authentication, broken access control, weak crypto, unsafe deserialization, and so on. The OWASP Cheat Sheet Series is the community's condensed, actionable guidance for each one. This skill makes that guidance usable on a real change: it routes you to the right cheat sheet, states the attack each control stops in plain terms, and, most important, it does not let a security control ship as advice. Every control must arrive with an executable @security BDD scenario that actually tests it, in the same place every other scenario runs.

Advice that is not tested rots. A comment that says "we validate input here" is not a control; a test that sends the attack and sees it rejected is. So this skill is the secure-coding half, and it leans on bdd-comprehensive-testing for the executable half: the secure-coding controls come from the cheat sheets, and the proof that they hold comes from @security scenarios wired into CI.

The non-negotiables

1. Find the relevant cheat sheet(s). For the change in front of you, look up the matching sheet in the catalog below (for example a login form touches Authentication, Session Management, Password Storage, and Credential Stuffing Prevention). Read its per-sheet file and apply the controls.
2. Threat-model with the attacker's view. Each per-sheet file states the real attack the control stops, grounded in a penetration-testing source, so you defend against what attackers actually do, not an abstract risk.
3. Every control ships an executable @security BDD scenario (not prose). When you apply a sheet to real code, write or update its @security Gherkin scenario and ADD IT to the repo's single shared feature-file index that bdd-comprehensive-testing owns (its "Storing BDD scenarios permanently" section), tagged @security, and wire it into CI (its "CI/CD wiring") so it runs as a blocking autotest in the same place as every other scenario. The scenario in each per-sheet file is the canonical copy to add; the per-sheet doc is not where tests run. A security control with no executable scenario in that shared index is not done.
4. Name the real guarantee. The scenario checks one attack is blocked; the structural control (a parameterized query, contextual output encoding, an Argon2id hash, a DB constraint) is what makes every case safe. State both, so no one mistakes a passing test for a proof.

The selection flow: OWASP threat modeling (required, enforced)

Choosing the right cheat sheets is not left to chance. Follow OWASP's own Threat Modeling Process, which runs in four steps, and the flow produces a security-decision record plus the executable scenarios the enforcement gate checks. This is the secure-coding analogue of how pattern-selector forces a deliberate pattern choice.

Step 1: Scope your work

Map the change's surface the way OWASP's first step does: the entry and exit points, the assets worth protecting, the trust boundaries the data crosses, and the data flows. From that surface, SELECT the cheat sheets that apply. For example, a login form that writes to SQL crosses an authentication trust boundary and touches a database, so it selects Authentication, Session Management, Password Storage, and SQL Injection Prevention.

Step 2: Determine threats

For the scoped surface, name what can go wrong using a categorization such as STRIDE, and map each threat to the cheat sheet that addresses it. Rank the threats high, medium, or low by exploitability and impact, as OWASP's process does, so the most dangerous are handled first.

Step 3: Determine countermeasures and mitigation

Apply each selected sheet's controls, preferring the structural one it names first. For every threat choose a risk response the way OWASP's third step frames it: eliminate, mitigate, transfer, or (rarely, with a stated reason) accept. A threat with no countermeasure is a vulnerability, not a decision. Add each control's @security scenario to the shared feature-file index (via bdd-comprehensive-testing), so the countermeasure is tested, not merely asserted.

Step 4: Assess your work (the security-decision record)

Record the result: the surface, the cheat sheets selected, the threats and their ranking, the countermeasures applied, the @security scenarios added (or the explicit, reasoned waivers), and the real guarantee for each. This security-decision record is the evidence that the flow ran, and it is exactly what OWASP's fourth step asks for: a scope, a threat list, and a control list that exist and are reviewable.

What makes this impossible to skip, and the honest limit

The flow is enforced at the OUTCOME, not on trust. scripts/check-security-coverage.mjs maps the changed code to the security surfaces it touches (SQL, auth, sessions, uploads, JWT, rendering, SSRF, command execution, deserialization, and more in assets/security-coverage.config.json) and FAILS the build when a triggered surface has no matching @security scenario in the feature index and no reasoned, unexpired waiver. So shipping security-relevant code with nothing testing it cannot pass CI, and it cannot regress silently, because the gate runs on every change and has a discriminating test. The honest limit: the gate makes it impossible to SKIP the flow or ship an untested surface; it cannot guarantee you picked the perfect set of sheets or wrote a perfect scenario. That judgment is caught by a judge-arch review, and every gap found becomes a new surface rule in the config, so the part that rests on judgment only shrinks.

The cheat-sheet catalog (the routing index)

Each OWASP cheat sheet is its own reference file under references/cheatsheets/<Slug>.md, loaded on demand. The authoritative list is references/cheatsheets-manifest.json (137 sheets, from the OWASP sitemap, retrieved 2026-10-10). All 137 are written to the per-sheet template with a cited, executable @security scenario. The check-cheatsheet-catalog.mjs gate keeps this honest: every sheet must have its file, every required section, a citation, an executable @security scenario, and an entry in this index.

Frontend & browser (16/16)

Backend: input, injection & data stores (15/15)

Backend: authentication & sessions (11/11)

Backend: authorization & access control (10/10)

Backend: handling, output & resources (8/8)

API & services (14/14)

Cryptography, secrets & transport (10/10)

Infrastructure, containers & cloud (10/10)

CI/CD & supply chain (6/6)

AI, LLM & agents (9/9)

Language & framework guides (16/16)

Mobile & embedded (3/3)

Security process & cross-cutting (9/9)

The per-sheet file template

Every references/cheatsheets/<Slug>.md follows the same shape, and the catalog gate enforces it:

• ## What it is : the sheet's scope in a sentence or two.
• ## The attack it stops : the real attack, grounded in the OWASP sheet and, where it maps, the attacker's view from a penetration-testing source.
• ## Controls : the condensed, actionable controls from the OWASP sheet, in its order of preference.
• ## @security scenario : a real, executable Gherkin @security scenario (the canonical copy to add to the shared feature index). The gate rejects prose here: it must contain a @security tag, Scenario:, and Given / When / Then.
• ## The real guarantee : the structural control that makes every case safe, versus what the scenario checks.
• ## Sources : the OWASP cheat-sheet URL with a retrieval date, plus any penetration-testing citation. Cite only what was read.

Mechanical gate

• scripts/check-security-coverage.mjs (test: test/owasp-security-coverage.test.mjs) is the enforcement gate for the selection flow. It maps the changed code to the security surfaces it touches (assets/security-coverage.config.json) and fails closed when a triggered surface has no matching @security scenario in the feature index and no valid waiver. This is what makes the flow impossible to skip on a security-relevant change. Adopters run it on their changed files in CI.
• scripts/check-cheatsheet-catalog.mjs (test: test/owasp-cheatsheet-catalog.test.mjs) fails closed unless every sheet has its file, all required sections, a citation URL, and an executable @security Gherkin scenario, and is indexed above, with no orphan files. It confirms all 137 are complete.
• scripts/check-owasp-lints.mjs (test: test/owasp-lints.test.mjs) is the code-level secure-coding lint (JWT alg:none, insecure cookie flags).
• The @security scenarios are validated as real runnable Gherkin by bdd-comprehensive-testing's check-gherkin-valid.mjs, and in an adopting repo they execute in CI through that skill's runner.

Before you call it done

• The selection flow ran: the change's surface was scoped, threats determined and ranked, and the cheat sheet(s) selected (OWASP threat modeling steps 1 and 2).
• Countermeasures applied, each with a risk response (eliminate, mitigate, transfer, or reasoned accept).
• Each control has an executable @security scenario in the repo's shared feature-file index, wired into CI, not just prose in the per-sheet doc.
• The structural guarantee is named, separate from what the scenario checks.
• The security-decision record (OWASP threat modeling step 4) exists: surface, sheets selected, threats and ranking, countermeasures, scenarios added or reasoned waivers, and the real guarantee for each.
• check-security-coverage.mjs, check-cheatsheet-catalog.mjs, and check-owasp-lints.mjs pass.
• The run records its evidence ledger: each control, the attack it stops, the @security scenario that tests it, and the source read, each with an evidence state and a re-runnable source.

Reference files

Evidence & skeptical assessment (required)

"This control is in place and tested" is a factual claim, so it follows the repo's evidence discipline (canonical contract: skeptical-audit/references/evidence-discipline.md). The deliverable for a change is its evidence ledger: each control, its attack, its @security scenario, and the source read, each with a state and a re-runnable source.

Definition of done: the right sheets are applied; every control has an executable @security scenario in the shared feature index wired into CI; the structural guarantee is named; both gates pass; and the evidence ledger is recorded. A security control with no scenario in the shared index is not-assessed, never a pass.

Why this holds for every developer and every agent

It binds everyone because the controls, the per-sheet files, the catalog gate, and the @security scenarios live in committed files and CI, not memory. Agents get it through the always-on hook, which lists this skill in always-on/enterprise-skills-always-on.md. People and agents alike are held by the catalog gate (no half-written sheet merges) and by the shared feature index plus bdd-comprehensive-testing's gherkin and coverage gates (a security control with no runnable scenario does not merge). It survives any one person because everything is in git. The honest limit: the catalog gate proves a sheet is complete and its scenario is real Gherkin, and the BDD gates prove the scenario runs; none of them proves the control is the right one for the threat, which is why the attacker-view threat modeling and a judge-arch review sit alongside. A second honest limit: each per-sheet file condenses a single OWASP cheat sheet, so it inherits that one source's coverage and currency. This matters most for the fast-moving AI and LLM sheets; for those, treat the condensed file as a routing entry point and read the live upstream sheet (and OWASP's separate AI/LLM project) before relying on it.

Sources and attribution

• OWASP Cheat Sheet Series (https://cheatsheetseries.owasp.org/, index retrieved 2026-10-10): the 137 cheat sheets this skill routes to; each per-sheet file cites the specific sheet it condenses, read this session. [documented]
• Georgia Weidman, Penetration Testing: A Hands-On Introduction to Hacking (No Starch Press, 2014, ISBN 978-1-59327-564-8): the attacker's view that hardens the per-sheet files, cited per sheet from the chapters read this session. [documented]
• bdd-comprehensive-testing (this repo): owns the shared feature-file index, the official-parser gherkin validation, and the CI wiring that runs the @security scenarios. [documented]

Where this skill's scripts run

Every script this skill ships declares an install scope in a comment marker, and esk-genesis installs only what the gate manifest lists. Which scripts run in a consumer repo, which are enforced there, and which govern only this authoring repo are defined by gate-manifest.json and ADR-0109, not restated here, so there is one source of truth.