🛡️ Sentinel: [CRITICAL] Fix SQL injection vulnerability in ERDModel

.jules/sentinel.md

@@ -20,3 +20,13 @@
 **Vulnerability:** The standard user authentication routes (login, register, and reset-password) did not have a maximum length constraint on passwords. This allows an attacker to supply extremely long strings, which `bcrypt` will try to hash, causing CPU exhaustion and creating a Denial of Service (DoS) vulnerability.
 **Learning:** `bcrypt` (and `bcryptjs`) is intentionally slow. While `bcrypt` may internally truncate passwords to 72 bytes, depending on the implementation the input string processing itself or the full string parsing before truncation can be very costly. In this codebase, the admin authentication correctly checked for a max length, but user schemas did not.
 **Prevention:** Always enforce a maximum string length limit (e.g. `.max(1024)`) on user inputs that will be passed into expensive algorithms like bcrypt hashing.
+
+## 2025-02-18 - [ERD 모델의 SQL 인젝션 및 상태 변이 우회 취약점 수정]
+**Vulnerability:** `ERDModel` 클래스에서 컬럼 타입 및 기본값에 대한 정규식 검증이 누락되어 악의적인 SQL 문법이 삽입될 수 있었으며, 내부 상태 객체(테이블)가 직접 반환되어 검증 로직을 우회하여 상태 변이가 발생할 수 있었습니다.
+**Learning:** DDL 생성 시 자유 텍스트나 타입 입력이 포함될 때는 반드시 허용 목록(Allowlist) 기반 정규식을 사용해야 하며, 객체 상태를 반환할 때는 캡슐화를 보장하기 위해 깊은 복사(Deep Copy)를 수행해야 검증 우회를 방지할 수 있습니다.
+**Prevention:** 정규식(예: `SAFE_SQL_TYPE`, `SAFE_SQL_DEFAULT_VALUE`)을 도입하여 타입과 기본값을 검증하고, 객체를 반환할 때 `JSON.parse(JSON.stringify(table))`를 사용하여 원본 참조를 숨깁니다.
+
+## 2026-07-02 - [Fix High Severity Vulnerability in js-yaml]
+**Vulnerability:** `js-yaml` versions 4.0.0 through versions below 4.3.0 were affected by quadratic CPU consumption in YAML merge-key chains (CVE-2026-59869, GHSA-52cp-r559-cp3m), allowing crafted YAML input to cause denial of service. Version 4.3.0 is patched.
+**Learning:** `pnpm` 환경에서 서드파티 패키지의 하위 의존성에 존재하는 취약점을 수정할 때, 직접적인 `package.json` 업데이트로 해결되지 않는다면 `pnpm.overrides`를 적극 활용하여 전체 프로젝트 수준에서 특정 안전한 버전을 강제할 수 있습니다.
+**Prevention:** `pnpm audit`과 같은 도구를 주기적으로 실행하여 취약점을 점검하고, 루트 `package.json`의 `"pnpm": { "overrides": { ... } }` 구문을 사용해 취약점이 패치된 버전을 고정(pin)합니다.

CHANGELOG.md

@@ -4,6 +4,7 @@
 
 ### 🛡️ 보안 (Security)
 
+- ERD DDL 생성 경계를 구조적 allow-list 방식으로 강화했습니다. 지원하는 PostgreSQL 타입 문법과 제한된 side-effect-free 기본값만 허용하고, 컬럼 제약·임의 함수 호출·잘못된 런타임 타입을 거부합니다. 검증된 컬럼·외래 키는 모델 소유 복사본으로 저장하며, 모든 식별자를 quoted identifier로 출력해 예약어 충돌과 검증 후 객체 변이 우회를 차단합니다. 관련 회귀 테스트와 `docs/doctoring/erd-ddl-injection-boundary.md`에 위협 모델·롤백·APA 7 근거를 기록했습니다.
 - 로그인, 회원가입, 비밀번호 재설정이 하나의 공유 비밀번호 계약을 사용하도록 통합했습니다. 입력 처리량을 1,024자로 먼저 제한하고, 현재 `bcryptjs`가 완전하게 검증할 수 있는 72 UTF-8 바이트를 초과하는 값은 조용히 잘라내지 않고 거부합니다. ASCII와 다중 바이트 Unicode 경계 회귀 테스트 및 운영·표준 근거 문서를 함께 추가했습니다.
 
 ### ⚡ 성능 (Performance)

docs/doctoring/erd-ddl-injection-boundary.md

@@ -0,0 +1,76 @@
+# ERD DDL injection boundary
+
+## Scope
+
+`packages/web/src/lib/erd.ts` generates PostgreSQL `CREATE TABLE` text from the in-memory ERD model. This is a code-generation boundary rather than a normal parameterized DML query: SQL identifiers, data types, and selected default expressions occupy grammar positions where bind parameters are not generally available. The safe contract is therefore **positive allow-list validation plus explicit identifier quoting**, not deny-listing individual punctuation characters.
+
+This document governs the `ERDModel` surface only. Generated DDL is still executable administrative input and must be reviewed and executed under least privilege in downstream migration tooling.
+
+## Threat model
+
+The relevant attacker controls or influences table/column metadata before `ERDModel.generateDDL()` is called. The security goals are:
+
+1. A value supplied as a data type cannot smuggle a column constraint, reference, check expression, second statement, comment, operator, or unknown type grammar into the generated DDL.
+2. A default value cannot invoke an arbitrary database function or inject another SQL statement.
+3. A caller cannot mutate a previously validated `Column` or `ForeignKey` object after insertion and thereby change model-owned state without validation.
+4. Accepted snake_case names remain valid even if they coincide with PostgreSQL keywords, because every generated identifier is double-quoted.
+5. Malformed runtime values that bypass TypeScript's compile-time types fail closed before they reach grammar validation or model storage.
+
+## Accepted grammar
+
+### Identifiers
+
+Database object identifiers use lower-case snake_case and are always emitted as PostgreSQL quoted identifiers. This keeps the storage naming policy deterministic and prevents accepted words such as `select` or `from` from becoming ambiguous SQL grammar.
+
+### Data types
+
+The model accepts only the reviewed type families encoded in `SIMPLE_SQL_TYPES`, `MULTI_WORD_SQL_TYPES`, and `PARAMETERIZED_SQL_TYPE`. Supported parameterized types are bounded to integer arity for `CHAR`, `VARCHAR`, `CHARACTER VARYING`, `NUMERIC`, and `DECIMAL`.
+
+Column constraints such as `PRIMARY KEY`, `NOT NULL`, `UNIQUE`, `REFERENCES`, and `CHECK` are intentionally not part of `Column.type`. PostgreSQL documents a column definition as a data type followed by separate column-constraint grammar. Keeping those grammar slots distinct prevents a caller from bypassing the model's dedicated constraint fields.
+
+### Default values
+
+Defaults accept only:
+
+- SQL single-quoted scalar strings, including standard doubled-quote escaping;
+- signed integer or decimal literals;
+- `TRUE`, `FALSE`, and `NULL`;
+- reviewed current-time keywords (`CURRENT_DATE`, `CURRENT_TIME`, `CURRENT_TIMESTAMP`, `LOCALTIME`, `LOCALTIMESTAMP`); and
+- `now()` as the sole reviewed function-form default.
+
+Arbitrary function calls, malformed strings, statement terminators, and other expressions are rejected. If future product requirements need additional PostgreSQL expressions, extend the allow-list test-first rather than broadening it to a generic SQL-token regex.
+
+## Validated-state ownership
+
+`addColumn()` and `addForeignKey()` validate primitive runtime types and SQL/name contracts, then copy accepted fields into model-owned objects. `addTable()`, `getTable()`, and `getTables()` return independent plain-data snapshots. This makes validation stable across the lifetime of a model: mutating a caller-owned input or returned snapshot cannot alter the internal model.
+
+## Verification contract
+
+The ERD regression suite must continue to cover at least:
+
+- legal simple, multi-word, and parameterized PostgreSQL type forms;
+- grammar-smuggling attempts such as `INTEGER PRIMARY KEY`, `TEXT NOT NULL`, `INTEGER UNIQUE`, `INTEGER REFERENCES ...`, and `CHECK` expressions;
+- unknown type names;
+- scalar and reviewed built-in defaults;
+- arbitrary function defaults and malformed quoted strings;
+- malformed runtime field types despite TypeScript declarations;
+- mutation of caller-owned column and foreign-key objects after insertion;
+- independent getter snapshots;
+- quoted DDL for normal and reserved-word identifiers; and
+- multi-table foreign-key DDL.
+
+Repository CI, security scanning, supply-chain checks, exact-head automated review, and independent approval remain separate merge gates. A predecessor-head pass does not prove a later head.
+
+## Failure and rollback
+
+This boundary is fail-closed. A newly requested type or default expression that is not explicitly supported is rejected instead of passed through. If compatibility pressure reveals a legitimate missing PostgreSQL form, add a focused failing regression, extend the smallest relevant allow-list, and rerun the complete exact-head suite.
+
+Rollback of this hardening must not restore free-form type/default concatenation or semicolon-only filtering. If the ERD DDL generator must temporarily lose a capability, prefer disabling unsupported DDL export over accepting unvalidated grammar.
+
+## References (APA 7th)
+
+Open Worldwide Application Security Project. (n.d.). *Input validation cheat sheet*. OWASP Cheat Sheet Series. Retrieved August 7, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
+
+Open Worldwide Application Security Project. (n.d.). *SQL injection prevention cheat sheet*. OWASP Cheat Sheet Series. Retrieved August 7, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
+
+PostgreSQL Global Development Group. (2026). *CREATE TABLE*. In *PostgreSQL 18 documentation*. https://www.postgresql.org/docs/18/sql-createtable.html