/security

name: blueprint-cloudflare-security
description: "Review the finished Worker against OWASP Top 10:2025, fix what is exploitable, prove each fix with a test, and report."

Security review

The app is built and runs. Before it is published, review it the way an attacker would read it, fix what is exploitable, and leave a report the person can read. The check does not take your word for it: it starts the Worker with wrangler dev and sends it the requests an attack would send.

Method

1. **Context.** Read `.blueprint/spec.md` (above all "必ず詰める点"), then `src/worker/`, `src/client/`, `wrangler.jsonc`, `public/_headers` and `package.json`. Note who may do what, where input enters, what is stored. 2. **Audit, category by category** (the list below). For each place input enters, trace it to where it is used. 3. **Fix** every HIGH and MEDIUM finding, and add a test to `test/security.test.ts` that fails without the fix. 4. **Report** in `.blueprint/security-review.md` (format below).

Severity: **HIGH** is directly exploitable (read or change someone's data, bypass sign-in, run code). **MEDIUM** needs a specific condition but the impact is real. **LOW** is defence in depth. Report a finding only when you can state how it is exploited and you are at least 70% sure. Do not report denial of service, rate limits, or missing validation on a field that cannot cause harm.

What to look at in this app (OWASP Top 10:2025)

• **A01 Broken Access Control** — the app is public: every `/api` route enforces the spec's sign-in and roles in the

Worker; with accounts, a row is read or changed only by whoever may.

• **A02 Security Misconfiguration** — security headers on every response: the Worker's for `/api/*`, and

`public/_headers` for the static files, which never go through the Worker; no permissive CORS.

• **A03 Software Supply Chain Failures** — `yarn audit --groups dependencies` has no high or critical.
• **A04 Cryptographic Failures** — passwords as salted PBKDF2 (Web Crypto), compared in constant time; secrets as

wrangler secrets, and `.dev.vars` (and any `.env`) listed in `.gitignore`; cookies `HttpOnly`, `Secure`, `SameSite=Lax`.

• **A05 Injection** — SQL only with bound parameters; the screen never renders input as HTML.
• **A06 Insecure Design** — the spec's rules are enforced in the Worker, not only on the screen.
• **A07 Authentication Failures** — a new session at sign-in; sign-out ends it; no default password in the code.
• **A08 Software or Data Integrity Failures** — nothing from a request picks code to run; an uploaded file is

checked for type and size.

• **A09 Security Logging and Alerting Failures** — sign-in failures and changes to data are logged (`console.log`

reaches `wrangler tail`), without passwords, cookies or secrets.

• **A10 Mishandling of Exceptional Conditions** — every error reaches one handler that answers JSON without a stack;

a failed check refuses rather than lets through.

What the check sends, and must get back

• A POST under `/api` from `Origin: https://attacker.example` → **403**, before routing and sign-in.
• A POST under `/api` with a malformed JSON body → **400**, from the one place the Worker reads bodies, with no

stack trace or parser message.

• `/` and `/api/health`: `Content-Security-Policy` with `frame-ancestors 'none'`, `X-Content-Type-Options: nosniff`,

no `X-Powered-By`.

• `.dev.vars` / `.env`, if present, ignored by `.gitignore`.

The report

`.blueprint/security-review.md`, in the spec's language. One section per category, its heading naming the id (`## A01 …` through `## A10 …`), every finding on a line of its own:

- HIGH fixed: <what was wrong, how it could be exploited> — <what changed, which test proves it>
- LOW accepted: <what, and why it is acceptable for this app>

The state is `fixed`, `open` or `accepted`; a HIGH or MEDIUM may be neither `open` nor `accepted`. A category with nothing to report says what was checked and "指摘なし".

Done when the check passes: the report covers A01–A10 with nothing HIGH or MEDIUM left open, the tests pass, the audit is clean, and the running Worker refuses the cross-site change and the malformed body and sends the headers.

Always

• Read `.blueprint/spec.md` first. It is the agreed specification; do not widen it.
• When you need a decision, ask it through the blueprint question tool and stop. Do not guess.
• Do not run `git init`: a new repository loses the folder's trust and the next unattended step stops at Claude

Code's trust prompt. The user adds git themselves after the build if they want it.

• Say you are done by stopping; the executor runs the check. Do not claim success yourself.