Blueprint Local Security

Security review

The app is built and runs. Before it is handed over, 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 built server and sends it the requests an attack would send.

Method

1. Context. Read .blueprint/spec.md (above all "必ず詰める点"), then all of server/, client/src/ and package.json. Note who may do what, where input enters, and 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; a guess is not a finding. Do not report denial of service, rate limits, memory or CPU exhaustion, 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 — every /api route enforces the spec's sign-in and roles on the server; with accounts, a row is read or changed only by whoever may (no id-guessing into another person's data). DNS rebinding: listening on 127.0.0.1 is not enough, because a web page can point its own name at 127.0.0.1 and then call this API as a same-origin page. Refuse any request whose Host is not on the allow-list.
• A02 Security Misconfiguration — security headers on every response; x-powered-by off; no permissive CORS; the default host stays 127.0.0.1.
• A03 Software Supply Chain Failures — yarn audit --groups dependencies has no high or critical; the lockfile is kept; no dependency the app does not use.
• A04 Cryptographic Failures — passwords as salted scrypt, compared with timingSafeEqual; the session secret random and in .env, with .env listed in .gitignore (add it if it is not; the check fails on an .env that is not ignored); cookies HttpOnly and SameSite=Lax.
• A05 Injection — SQL only with placeholders; no shell command, file path or eval built from input; the screen never renders input as HTML (v-html only on text the app itself wrote).
• A06 Insecure Design — the spec's rules (limits, states, who may change what) are enforced on the server, not only on the screen; a body size limit on the JSON parser.
• A07 Authentication Failures — a new session id at sign-in; sign-out ends the session on the server; no default or shared password in the code.
• A08 Software or Data Integrity Failures — nothing from a request is deserialised into code or used to pick a module; an uploaded file is checked for type and size.
• A09 Security Logging and Alerting Failures — sign-in failures and changes to data are logged, without passwords, cookies or secrets.
• A10 Mishandling of Exceptional Conditions — every error reaches one handler that answers JSON without a stack trace or a parser's message; a failed check refuses rather than lets through.