IMPL PLAN 10 — Frontend Static Client (Angular 21 บน Cloudflare)

วันที่: 07/07/2026 · สถานะ: ⏳ รอ verify · Priority: 🟠 คู่กับ Phase 1-2 อ้างอิง: IMPL_PLAN_02 §1/§3/§4 (กลไก key/signature/encryption) · IMPL_PLAN_03 §3.1 (subscription key ฝั่ง APIM) · DISCUSSION หมวด 2-3

เอกสารนี้ตอบอะไร

แผน 02/03 ตอบ “กลไกคืออะไร ฝั่ง server ทำอะไร” แล้ว — เล่มนี้ตอบมุมกลับ: client เป็น Angular 21 build เป็น static HTML/JS วางบน Cloudflare (ไม่มี server-side runtime ของตัวเอง) จะรองรับ 3 requirement ใหม่ได้ยังไง และต้องตัดสินใจอะไรบ้างก่อนลงมือ

หลักการตั้งต้น (จำให้ขึ้นใจก่อนหารือ):

ทุก byte ใน static bundle = public — ใครก็ view-source/devtools ได้ ดังนั้นของที่ฝังใน bundle ได้มีแค่ 2 ชนิด: (ก) ของที่เป็น public โดยนิยาม (RSA public key, API base URL) และ (ข) ของที่ยอมรับว่าเห็นได้เพราะไม่ใช่เกราะ (subscription key = app identity) ความลับจริงทุกตัวต้องมาจาก server หลัง authenticate (session-bound key) หรือไม่ต้องมีเลย (asymmetric)

§1 สรุป posture ที่แนะนำ ต่อ requirement (ตารางตัดสินใจสำหรับที่ประชุม)

ประเด็นที่ต้องสื่อสารกับผู้ตั้ง requirement: ถ้า requirement เขียนว่า “client ต้อง sign body ด้วย shared secret” แบบตายตัว — สถาปัตยกรรม static SPA ทำแบบนั้นอย่างปลอดภัยไม่ได้ (secret จะกลายเป็น public ทันที) ทางที่เทียบเท่าหรือดีกว่าคือ session-bound key (D10-2) — ต้องเจรจา scope กับผู้ตรวจด้วยเหตุผลนี้ ไม่ใช่ฝืน implement แบบ security theater

§2 ปัญหาเฉพาะ static hosting: Config ต่อ Environment มาจากไหน

Static HTML deploy ครั้งเดียวเสิร์ฟทุกคน — ไม่มี server-side template ที่จะฉีดค่า per-env ตอน request ดังนั้นต้องเลือกวิธี inject config (subscription key, API base, RSA public key kid):

งานถ้าเลือก (B):

§3 Sequence Diagram — Client Bootstrap → ใช้งานครบ 3 กลไก

sequenceDiagram
    autonumber
    participant B as Browser (Angular 21 SPA)
    participant CF as Cloudflare (static + WAF)
    participant APIM as APIM
    participant SG as Sentinel
    participant BE as Backend

    Note over B,CF: ① Bootstrap (ทุกครั้งที่เปิด app)
    B->>CF: GET /index.html + bundle (cached, hashed)
    B->>CF: GET /config.json (no-cache)
    CF-->>B: { apiBase, subscriptionKey, cryptoKeyEndpoint }

    Note over B,SG: ② Login (flow เดิม — OIDC ผ่าน Sentinel)
    B->>SG: /sentinel/login → OIDC PKCE
    SG-->>B: Set-Cookie HttpOnly<br/>(+ Phase 2: signingKey ใน /sentinel/user → เก็บ memory เท่านั้น)

    Note over B,BE: ③ เรียก API ปกติ
    B->>B: interceptor แนบ Ocp-Apim-Subscription-Key<br/>(+ Phase 2: X-Signature/X-Timestamp ผ่าน Web Crypto HMAC)
    B->>APIM: POST /api/... + Cookie + headers
    APIM->>APIM: validate subscription key → rate limit → resolve-session → validate-jwt
    APIM->>BE: forward + JWT

    Note over B,BE: ④ Form ที่มี field อ่อนไหว (ตาม PII inventory)
    B->>BE: GET /api/v1/crypto/public-key (cache ตาม kid)
    B->>B: crypto.subtle.encrypt(RSA-OAEP, publicKey, citizenId)
    B->>APIM: POST { citizenId: "rsa:<kid>:<b64>", ... }
    BE->>BE: decrypt ผ่าน KV Keys API (private key ไม่ออกจาก vault)
    BE-->>B: 200

§4 Activity Diagram — เลือกกลไกต่อ request ยังไง

flowchart TD
    A[Request จาก Angular SPA] --> B{มี field อ่อนไหวสูง<br/>ตาม PII inventory?}
    B -- ใช่ --> C[เข้ารหัส field นั้นด้วย RSA-OAEP<br/>ก่อนใส่ body]
    B -- ไม่ --> D[body ปกติ — TLS ครอบ]
    C --> E{Phase 2 เปิดแล้ว +<br/>เป็น write operation?}
    D --> E
    E -- ใช่ --> F[HMAC sign ด้วย session key<br/>จาก memory → X-Signature/X-Timestamp]
    E -- ไม่ --> G[ไม่ sign]
    F --> H[interceptor แนบ subscription key<br/>+ cookie ไปเองอัตโนมัติ]
    G --> H
    H --> I[ส่งผ่าน Cloudflare → APIM]

    style C fill:#e6f0ff
    style F fill:#fff3e0

§5 ทางเลือก: Cloudflare Worker เป็น thin proxy — คุ้มไหม

คำถามที่จะโดนถามแน่: “ในเมื่อ host บน Cloudflare อยู่แล้ว ใช้ Worker ซ่อน subscription key ได้ไหม?”

ข้อเสนอ: ไม่ใช้ Worker ใน phase นี้ — เก็บเป็น fallback หากผู้ตรวจยืนยันว่า key ห้ามปรากฏใน client เท่านั้น (บันทึกเป็น decision D10-1)

§6 ข้อจำกัด runtime ฝั่ง browser ที่ต้องแจ้งทีมล่วงหน้า

§7 ลำดับงานฝั่ง Frontend (สอดคล้าง phase ของแผนหลัก)

§8 Report Client — เอา data มา render เอง ต้องระวังอะไร

Governance/backend control ของ use case นี้อยู่ครบใน S12 แล้ว — section นี้ตอบเฉพาะมุม static client + คำถาม “data จะถูกดัดแปลงไหม”

8.1 ตอบตรงเรื่อง tampering — แยก 3 ขา

สรุปให้ที่ประชุม: ความเสี่ยงจริงของ report client ไม่ใช่ “ข้อมูลถูกแก้ระหว่างทาง” (TLS ปิดแล้ว) แต่คือ (ก) ส่ง data เกินจำเป็นไปให้ client และ (ข) ไม่มีต้นฉบับให้ตรวจเมื่อ report ถูกใช้เป็นหลักฐาน — สองข้อนี้แก้ที่ backend ไม่ใช่ที่ Angular

8.2 งานฝั่ง Angular (report page/component)

8.3 สิ่งที่ backend ต้องมีให้ (dependency — ชี้ไป S12)

• Report-specific DTO + permission check + tenant/user scope ต่อ report (S12 §1-2)
• Cache-Control: no-store, private บน response ที่มี PII (S12 §3)
• Audit ทุก report P0/P1: ใคร, report อะไร, filter อะไร (masked), กี่ record (S12 §5)
• Canonical hash / server-side PDF สำหรับ report ที่เป็นหลักฐาน (S12 §6 + D10-4)

§9 หลักฐานจากการ scan โครงสร้างจริง (07/07/2026 — Frontend_HostAppSuperApp + Frontend_SuperAppLibraryUi)

ตอบข้อสงสัย “client หละหลวมไหม” — scan ด้วย grep pattern เบื้องต้น (ยังไม่ใช่ full audit) พบของจริงหลายจุด — ข้อสังเกตถูกต้อง มีช่องโหว่จริงให้ prove ได้ เรียงตามความรุนแรง:

สิ่งที่ยังไม่ได้ตรวจ (อย่า assume ว่าผ่าน): CSP header จริงบน Cloudflare · console strip ใน production build config · dependency vulnerability (รอ Dependency-Track จาก IMPL_PLAN_01) · remote MF apps อื่น (ดูเฉพาะ shell + LibraryUi)

งานที่เพิ่มเข้า §7: F1/F5 = แก้ทันที (Phase 0 ของฝั่ง FE) · F2-F4, F7 = Phase 1 · CI grep gate (localStorage.*token|console\.log.*user|bypassSecurityTrust) เข้า regression gates ของ IMPL_PLAN_01 A9

Verify

• config.json เปลี่ยนค่า → app รับค่าใหม่โดยไม่ rebuild (ทดสอบ rotate subscription key)
• devtools network: ทุก API request มี Ocp-Apim-Subscription-Key · ไม่มี key → APIM ตอบ 401 (ไม่ถึง backend)
• form อ่อนไหว: network tab เห็น rsa:<kid>:... ไม่เห็น plaintext
• (Phase 2) refresh หน้า → request แรกหลัง bootstrap ยังมี signature ถูกต้อง (ไม่มี race)
• grep -rn "localStorage\|sessionStorage" ใน shell — ไม่มี key/token/PII ถูกเก็บ
• Cloudflare response headers มี CSP ครบ + config.json ไม่ติด long-cache
• Report: devtools network เห็นเฉพาะ field ที่หน้าจอใช้ (ไม่มี entity เต็ม) · response header Cache-Control: no-store · route/query ไม่มี PII
• Report: user A เปลี่ยน report id/filter เป็นของ user B → 403 (negative test ตาม S9)

⚠️ ข้อควรระวัง

1. ห้าม commit subscription key ค่าจริงลง git — แม้เป็น app identity การ rotate จะยากถ้าฝังใน history (บทเรียนเดียวกับ IMPL_PLAN_06)
2. ลำดับ enforce subscription key: แจก key ให้ทุก client (web/mobile/partner) + monitor ว่า traffic มี key ครบ → ค่อยเปิดบังคับที่ APIM — เปิดก่อน = client เดิมพังหมด (IMPL_PLAN_03 ข้อระวัง #1)
3. อย่าเสนอ “เข้ารหัส response ให้ browser” ในที่ประชุม — เป็น security theater (IMPL_PLAN_02 §4.3) ถ้าผู้ตรวจขอ ให้ตอบด้วย minimization + masking
4. Angular 21: ใช้ provideAppInitializer (functional) ไม่ใช่ APP_INITIALIZER token แบบเก่า — สอดคล้อง standalone/signals convention ของ repo

🎯 ถ้าเป็นผมจะทำอย่างไร (ความเห็น Fable)

1. แก้ F1 (report token ใน localStorage) ก่อนทุกอย่าง — เป็น diff เล็ก (ตัด 3 บรรทัด) แต่ปิดช่อง XSS-steal-token ที่ชัดที่สุดใน repo — ไม่ต้องรอที่ประชุม
2. เลือกทาง (B) runtime config — build-once คือวินัยที่จะขอบคุณตอน rotate subscription key ครั้งแรก · ไม่ใช้ Cloudflare Worker — เพิ่ม component โดยไม่เพิ่มความปลอดภัยจริง
3. Body signature ขา browser: เจรจา scope ก่อน implement — ผมจะไม่ทำ session-bound key (§3 ของ PLAN 02) จนกว่าผู้ตรวจจะยืนยันเป็นลายลักษณ์อักษรว่า scope ครอบ browser — effort สูง ผลตอบแทนต่ำเมื่อเทียบ TLS+cookie+CSRF ที่มีอยู่
4. RSA field encryption ทำเฉพาะ form P0 จริงๆ (KYC, เลขบัตร) — เริ่มหลัง PII inventory ของ UserService เสร็จ อย่าทำก่อนมี list
5. F5 (text-editor sanitize=false) ผมจะ flip default เป็น true ทันที แม้จะ breaking — ให้จุดที่เสีย formatting opt-out เอง ดีกว่าปล่อย stored-XSS surface เปิดไว้ default
6. Report client: สิ่งเดียวที่ผมจะลงทุนเกิน checklist §8 คือ report-specific DTO — เพราะ excessive data exposure เป็นความเสี่ยงจริงที่เกิดแล้วเกิดอีก ส่วน tampering ฝั่ง client เป็นความเสี่ยงที่รับได้ถ้า backend ไม่ trust derived value
7. ลำดับที่ผมจะทำ: F1+F5 → runtime config → subscription key interceptor → console/log hygiene (F3/F4) → RSA encryption → (ถ้าจำเป็น) session-bound signature

📚 อ้างอิงมาตรฐาน (สำหรับใช้ในที่ประชุม):