ข
ติวสอบภาค ข
PRO
กลับไปทำข้อสอบวิชานี้

ความรู้เกี่ยวกับการพัฒนาโปรแกรมระบบงานในลักษณะ Web Application

ครบวงจรจากต้นฉบับตรงวิชาและชุดข้อมูลเดิม 150 ข้อ เสริมมาตรฐานปัจจุบัน: HTTP RFC 9110, OWASP Top 10:2025 และ WCAG 2.2

18 หัวข้อ · อ่านประมาณ 194 นาที

อ่านฟรีได้ 2 จาก 18 หัวข้อ11%
สารบัญ18 หัวข้อหลัก
  1. 1.บทนำ — ขอบเขตวิชาและมาตรฐานอ้างอิงที่ตรวจแล้ว
  2. 2.REST/API Contract ที่ใช้งานจริง
  3. 3.Design Principles และ Code Quality
  4. 4.พื้นฐาน Web Application และสถาปัตยกรรมระบบ — หลักการทำงานของ HTTP/HTTPS Protocol
  5. 5.พื้นฐาน Web Application และสถาปัตยกรรมระบบ — โครงสร้างของ Web Server และ Application Server
  6. 6.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application › ส่วนที่ 1: Front-end — ส่วนที่ผู้ใช้มองเห็น — JavaScript พื้นฐานและ ES6+
  7. 7.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application › ส่วนที่ 2: Back-end — เครื่องยนต์เบื้องหลัง — Framework ฝั่ง Back-end
  8. 8.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application › ส่วนที่ 4: การจัดการ Authentication และ Session — Session และ Cookie
  9. 9.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application — สรุปประเด็นสำคัญประจำบท
  10. 10.ฐานข้อมูลและการจัดการข้อมูลใน Web Application — การเขียน SQL พื้นฐาน
  11. 11.ฐานข้อมูลและการจัดการข้อมูลใน Web Application › การเชื่อมต่อฐานข้อมูลด้วย ORM — แนวคิดของ ORM (Object-Relational Mapping)
  12. 12.ฐานข้อมูลและการจัดการข้อมูลใน Web Application — Database Connection Pooling
  13. 13.ฐานข้อมูลและการจัดการข้อมูลใน Web Application › การออกแบบ Index เพื่อเพิ่มประสิทธิภาพ — Index คืออะไรและทำงานอย่างไร
  14. 14.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application › OWASP Top 10 และช่องโหว่ความปลอดภัยที่พบบ่อย — XSS (Cross-Site Scripting)
  15. 15.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — การเข้ารหัสข้อมูลด้วย SSL/TLS และ HTTPS
  16. 16.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — มาตรฐาน WCAG สำหรับ Accessibility
  17. 17.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — กระบวนการ SDLC และ Agile/Scrum
  18. 18.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — การ Deploy และ CI/CD Pipeline
หัวข้อ 1

บทนำ — ขอบเขตวิชาและมาตรฐานอ้างอิงที่ตรวจแล้ว

Web Application คือระบบซอฟต์แวร์ที่ผู้ใช้เข้าถึงผ่าน Web user agent โดยอาศัยมาตรฐานเว็บและมักมีการประมวลผล/สถานะ/ข้อมูลฝั่ง Server หรือ Service ขอบเขตการพัฒนาจึงครอบ Requirement, UX/accessibility, frontend, backend/API, data, security, testing, deployment และ operation ไม่ใช่เพียงเขียนหน้า HTML

ขอบเขตวิชาและมาตรฐานอ้างอิงที่ตรวจแล้ว
แหล่งมาตรฐานหลักรุ่น/สถานะที่ใช้ในสรุปสิ่งที่ยึด
IETF RFC 9110HTTP Semantics, Internet StandardResource, method, safe/idempotent, status code และ HTTP semantics ร่วมทุกเวอร์ชัน
OWASP Top 10รุ่นเผยแพร่ 202510 หมวดความเสี่ยงล่าสุด; แยกจากชื่อหมวดรุ่น 2021 ในข้อมูลเดิม
W3C WCAGWCAG 2.2 Recommendation ฉบับ 12 ธันวาคม 2024หลัก POUR, Success Criteria และระดับ A/AA/AAA
HTML/CSS/ECMAScript/Web APIsLiving standards/มาตรฐานที่เปลี่ยนได้ตอบหลักเชิงแนวคิดและตรวจ compatibility ก่อนใช้ feature
OAuth 2.0 และ OpenID ConnectAuthorization framework กับ identity layerห้ามใช้คำสองคำนี้แทนกัน
เอกสารต้นฉบับตรงวิชาebooks-final ลำดับ 060พื้นฐาน เทคโนโลยี ฐานข้อมูล ความปลอดภัย SDLC และตารางทบทวนประเด็น

คำว่า “ล่าสุด” ในตารางเทคโนโลยีเปลี่ยนตามเวลา เนื้อหาจึงเน้น semantics และ trade-off ที่คงทน ส่วนชื่อ framework/ผลิตภัณฑ์เป็นตัวอย่าง ไม่ใช่ข้อสรุปสากล

Web site, Web Application, SPA, PWA และ Native app

  • Static site — ลักษณะเด่น: ส่งไฟล์ที่สร้างไว้ล่วงหน้า; อาจมี JavaScript/CDN/form ภายนอก; สิ่งที่ไม่ควรเหมารวม: Static ไม่ได้แปลว่าไม่มี interaction หรือไม่ปลอดภัยโดยอัตโนมัติ
  • Dynamic web — ลักษณะเด่น: Response/ข้อมูลเปลี่ยนตาม request, user, time หรือ backend; สิ่งที่ไม่ควรเหมารวม: อาจ render ที่ server หรือ client ก็ได้
  • Web Application — ลักษณะเด่น: มี workflow/state/business rule เช่น งานทะเบียนหรืออนุมัติ; สิ่งที่ไม่ควรเหมารวม: ไม่จำเป็นต้องเป็น SPA
  • SPA — ลักษณะเด่น: shell หน้าเดียวและเปลี่ยน view ด้วย client routing/data fetch; สิ่งที่ไม่ควรเหมารวม: URL, history, accessibility, SEO และ initial load ยังต้องออกแบบ
  • MPA — ลักษณะเด่น: navigation โหลด document ใหม่เป็นหลัก; สิ่งที่ไม่ควรเหมารวม: ไม่แปลว่าช้าหรือเก่า; progressive enhancement ทำ UX ดีได้
  • PWA — ลักษณะเด่น: ใช้ Web App Manifest, service worker และความสามารถติดตั้ง/ทำงานบางส่วนแบบ offline; สิ่งที่ไม่ควรเหมารวม: HTTPS และ service-worker lifecycle/cache invalidation เป็นประเด็นสำคัญ
  • Native mobile/desktop — ลักษณะเด่น: ติดตั้งและใช้ platform API โดยตรง; สิ่งที่ไม่ควรเหมารวม: แลก distribution, update, codebase และ capability กับเว็บ
  • Hybrid/cross-platform — ลักษณะเด่น: Web view หรือ runtime กลางห่อ application; สิ่งที่ไม่ควรเหมารวม: ประสิทธิภาพ/UX/permission ขึ้นกับสถาปัตยกรรมจริง

เลือกแนวทางจาก user journey, latency/offline, device capability, accessibility, SEO/discoverability, security, team skill, lifecycle และต้นทุนรวม ไม่เลือกจากคำว่า “modern”

ส่วนประกอบและเส้นทาง Request แบบ End-to-end

  1. 1ผู้ใช้/Browser สร้าง URL และตรวจ cache/service worker
  2. 2DNS resolve ชื่อเป็นปลายทาง
  3. 3สร้าง transport และ TLS สำหรับ HTTPS
  4. 4CDN/reverse proxy/WAF/load balancer รับ request
  5. 5Web/app server ตรวจ route, authn/authz, validation และ business rule
  6. 6cache/database/queue/external service ทำงาน
  7. 7สร้าง response/status/header/body
  8. 8Browser parse/render/execute และส่ง telemetry ตามนโยบาย
  • DNS — หน้าที่: Name resolution, TTL, routing บางแบบ; Failure/สิ่งที่ต้องสังเกต: NXDOMAIN, stale cache, propagation
  • TLS — หน้าที่: Confidentiality, integrity, server authentication ตาม certificate; Failure/สิ่งที่ต้องสังเกต: certificate/hostname/expiry/chain, downgrade/config
  • CDN/edge cache — หน้าที่: เสิร์ฟ content ใกล้ผู้ใช้และลด origin load; Failure/สิ่งที่ต้องสังเกต: cache key ผิด, stale/private data leak
  • Reverse proxy/gateway — หน้าที่: routing, TLS termination, policy, rate limit; Failure/สิ่งที่ต้องสังเกต: header trust, body/time limits, single point
  • Application — หน้าที่: business logic/orchestration; Failure/สิ่งที่ต้องสังเกต: exception, resource leak, race, dependency failure
  • Database/cache — หน้าที่: state/query/transaction; Failure/สิ่งที่ต้องสังเกต: contention, stale data, pool exhaustion
  • Queue/worker — หน้าที่: async work และ load leveling; Failure/สิ่งที่ต้องสังเกต: duplicate, poison message, backlog
  • Browser — หน้าที่: DOM/CSSOM/render/event/storage; Failure/สิ่งที่ต้องสังเกต: compatibility, XSS, performance, accessibility

HTTP เป็น stateless ในระดับ protocol แต่ application สร้าง state ได้ผ่าน cookie/session/token/database ห้ามสรุปว่า stateless เท่ากับไม่มี login หรือไม่มีข้อมูลสถานะ

Architecture: Layer, Tier และรูปแบบการติดตั้ง

  • Layer — ความหมาย: การแบ่งความรับผิดเชิงตรรกะใน code; ตัวอย่าง: presentation, application/use case, domain, data/infrastructure
  • Tier — ความหมาย: การแบ่งหน่วย deploy/process/machine เชิงกายภาพ; ตัวอย่าง: browser, app server, database server
  • Client–server — ความหมาย: client ขอ service; server ตอบตาม interface; ตัวอย่าง: browser ↔ web/API server
  • 2-tier — ความหมาย: client ติดต่อ data/service โดยตรงมาก; ตัวอย่าง: desktop client ↔ DB; coupling/security สูงกว่า
  • 3-tier — ความหมาย: presentation ↔ application ↔ data; ตัวอย่าง: UI ไม่เปิด DB credential โดยตรง
  • N-tier — ความหมาย: เพิ่ม gateway/service/cache/queue/integration ตามเหตุผล; ตัวอย่าง: จำนวน tier มากไม่เท่ากับคุณภาพดีกว่า
  • MVC — ความหมาย: Model–View–Controller แยก state/domain, presentation และ input coordination; ตัวอย่าง: รายละเอียด flow ต่างตาม framework
  • Clean/Hexagonal — ความหมาย: business rule อยู่แกนกลาง; dependency ชี้เข้า; adapter ต่อโลกภายนอก; ตัวอย่าง: ช่วย test/replace infrastructure แต่มี abstraction cost

ชั้น Presentation อาจมี presentation logic และ client validation ได้ แต่กฎธุรกิจที่ต้องเชื่อถือควรถูกบังคับฝั่ง Server/domain ด้วย การบอกว่า UI “ไม่มี logic เลย” จึงเป็นคำจำที่กว้างเกินจริง

Monolith, Modular monolith, Microservices และ Event-driven

  • Monolith — จุดแข็ง: deploy/test/transaction/trace ง่ายในช่วงต้น; ต้นทุน/เงื่อนไข: coupling และ release ใหญ่เมื่อ boundary ไม่ดี
  • Modular monolith — จุดแข็ง: process เดียวแต่ module/boundary ชัด; refactor/deploy ยังง่าย; ต้นทุน/เงื่อนไข: ต้องบังคับ dependency และ ownership จริง
  • Microservices — จุดแข็ง: deploy/scale/ownership แยกตาม business capability; ต้นทุน/เงื่อนไข: network failure, eventual consistency, observability, platform และ team coordination
  • Serverless/function style — จุดแข็ง: scale/operation บางส่วนเป็นภาระ platform; จ่ายตามรูปแบบใช้; ต้นทุน/เงื่อนไข: latency, limits, state/external connection, portability ตามผู้ให้บริการ
  • Event-driven — จุดแข็ง: decouple เวลาและ absorb burst; ต้นทุน/เงื่อนไข: ordering, duplicate, schema evolution, replay และ debugging
  • Micro-frontend — จุดแข็ง: ทีม/UI deploy แยก; ต้นทุน/เงื่อนไข: UX consistency, bundle/duplicate dependency, cross-app state/routing

เกณฑ์แยก service คือ bounded context, ownership, independent change/scale/failure—not จำนวนตารางหรือฟังก์ชัน เริ่มจาก boundary ที่เข้าใจและวัดปัญหาก่อน; distributed system เพิ่ม failure mode โดยธรรมชาติ

HTTP Semantics: Safe, Idempotent และ Cacheable

  • GET — เจตนามาตรฐาน: ขอ representation ของ resource; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: ผลตอบอาจเปลี่ยนตามเวลา; idempotent ไม่ได้แปลว่า response เท่าเดิม
  • HEAD — เจตนามาตรฐาน: เหมือน GET แต่ไม่มี response content; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: ใช้ดู metadata/condition โดยไม่รับ body
  • POST — เจตนามาตรฐาน: ให้ resource ประมวล representation ตาม semantics ของมัน; Safe: ไม่; Idempotent: ไม่โดยทั่วไป; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: อาจสร้าง/สั่งงาน; ทำ idempotency key ได้ระดับ application
  • PUT — เจตนามาตรฐาน: สร้างหรือแทน state ของ target resource ด้วย representation; Safe: ไม่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: retry ผลที่ตั้งใจเท่าเดิม แม้ log/time/response อาจต่าง
  • PATCH — เจตนามาตรฐาน: ใช้ชุดการเปลี่ยนแปลงบางส่วน; Safe: ไม่; Idempotent: ไม่รับประกัน; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: รูปแบบ patch อาจออกแบบให้ idempotent ได้
  • DELETE — เจตนามาตรฐาน: ขอให้ลบ association ของ target URI; Safe: ไม่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: เรียกซ้ำยังมี intended effect เดิม แต่ status อาจต่าง
  • OPTIONS — เจตนามาตรฐาน: ขอ communication options; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: ใช้กับ CORS preflight บางกรณี
  • CONNECT — เจตนามาตรฐาน: สร้าง tunnel; Safe: ไม่; Idempotent: ไม่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: proxy/tunnel use case
  • TRACE — เจตนามาตรฐาน: loop-back diagnostic; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: มักปิดใน production เพื่อลด attack surface

Safe หมายถึง client ไม่ได้ร้องขอให้เปลี่ยน state ไม่ใช่ไม่มี side effect เลย เช่น logging/metrics ทำได้ Idempotent หมายถึงผลที่ตั้งใจบน server จากคำขอเหมือนกันหลายครั้งเทียบครั้งเดียว ไม่ได้แปลว่า response bytes เท่ากัน

HTTP Request, Response, Headers และ Status

  • Method + target — ตัวอย่าง/หน้าที่: เจตนาและ URI/path/query ของ resource
  • Header — ตัวอย่าง/หน้าที่: Host, Accept, Content-Type, Authorization, Cookie, conditional/cache/tracing metadata
  • Content — ตัวอย่าง/หน้าที่: representation ที่ส่ง; semantics ขึ้นกับ method/content type
  • Origin/context — ตัวอย่าง/หน้าที่: scheme/host/port และ security context ของ browser
  • 1xx — ความหมาย: informational/interim; ตัวอย่างที่ต้องแยก: 100 Continue, 101 Switching Protocols
  • 2xx — ความหมาย: สำเร็จตาม semantics; ตัวอย่างที่ต้องแยก: 200 OK, 201 Created, 202 Accepted ยังไม่เสร็จ, 204 No Content
  • 3xx — ความหมาย: redirect/cache choice; ตัวอย่างที่ต้องแยก: 301/308 permanent; 302/303/307 semantics method ต่าง; 304 ใช้ cached representation
  • 4xx — ความหมาย: request/client context ทำให้ดำเนินไม่ได้; ตัวอย่างที่ต้องแยก: 400 syntax/validation ทั่วไป, 401 ต้องมี authentication challenge/credentials, 403 ไม่อนุญาต, 404 ไม่พบหรืออาจซ่อน, 409 conflict, 412 precondition, 422 content เข้าใจแต่ process ไม่ได้, 429 rate limit
  • 5xx — ความหมาย: server ไม่ทำ request ที่ดู valid สำเร็จ; ตัวอย่างที่ต้องแยก: 500 unexpected, 502 upstream response, 503 unavailable, 504 upstream timeout

Status code เป็นส่วนหนึ่งของ contract แต่ error body ควรมี code เชิงโดเมน ข้อความปลอดภัย correlation/trace ID และรายละเอียด field ที่ validate ไม่ผ่านโดยไม่รั่ว stack trace/secret

HTTP/1.1, HTTP/2, HTTP/3 และ TLS

  • HTTP semantics — แก่น: method/status/header/cache/resource; จึงต้องแยก: semantics ร่วมข้าม HTTP/1.1, 2 และ 3
  • HTTP/1.1 — แก่น: ข้อความบน TCP, persistent connection, request ordering ตาม connection; จึงต้องแยก: หลาย connection/keep-alive ไม่ใช่ multiplex แบบ HTTP/2
  • HTTP/2 — แก่น: binary framing, multiplex streams, header compression บน connection; จึงต้องแยก: ยังมี TCP-level head-of-line เมื่อ packet loss
  • HTTP/3 — แก่น: HTTP บน QUIC ซึ่งใช้ UDP transport และ TLS ใน QUIC; จึงต้องแยก: UDP ไม่ได้แปลว่าไม่มี reliability/security; QUIC จัดให้
  • HTTPS — แก่น: HTTP ผ่านช่องทางที่ authenticate/encrypt/integrity-protect ด้วย TLS; จึงต้องแยก: ไม่ได้รับประกันว่า server/app ปลอดช่องโหว่หรือเนื้อหาน่าเชื่อถือ
  • Certificate — แก่น: ผูก public key/identity ภายใต้ trust chain และ hostname/time validation; จึงต้องแยก: แม่กุญแจบอก secure transport ไม่ใช่ความซื่อสัตย์ของเจ้าของเนื้อหา

SSL เป็นโปรโตคอลรุ่นเก่าที่เลิกใช้ในการออกแบบสมัยใหม่ คำว่า SSL certificate มักเป็นภาษาพูด แต่การเชื่อมต่อจริงควรเป็น TLS ที่ตั้งค่าเหมาะสม

HTTP Caching, Validation และ CDN

  • Cache-Control — หน้าที่: กำหนด freshness/storage/revalidation เช่น max-age, no-store, private/public; ข้อควรระวัง: no-cache หมายถึงต้อง revalidate ไม่ใช่ห้ามเก็บ; no-store จึงต่าง
  • ETag + If-None-Match — หน้าที่: validator เชิง identifier ของ representation; ข้อควรระวัง: strong/weak semantics ต่าง; 304 ไม่มี representation ใหม่
  • Last-Modified + If-Modified-Since — หน้าที่: validator ตามเวลาแก้ไข; ข้อควรระวัง: ความละเอียดเวลา/clock ทำให้ไม่แม่นเท่า entity tag บางกรณี
  • Vary — หน้าที่: บอก request fields ที่เปลี่ยน representation/cache key; ข้อควรระวัง: ขาด Vary อาจเสิร์ฟภาษา/encoding/user variant ผิด
  • CDN — หน้าที่: shared cache/reverse proxy ใกล้ผู้ใช้; ข้อควรระวัง: ห้าม cache personalized response ด้วย key ไม่ครบ
  • Invalidation/versioning — หน้าที่: purge/tag หรือ immutable fingerprinted asset; ข้อควรระวัง: cache invalidation เป็น consistency problem
  • Service worker cache — หน้าที่: programmable browser-side offline/cache; ข้อควรระวัง: stale shell/data และ lifecycle update ต้องออกแบบ

Cache มีหลายชั้น: browser, service worker, CDN/proxy, application cache และ database cache ต้องรู้ owner, key, TTL, invalidation, stampede protection และ privacy ของแต่ละชั้น

URL, URI, Origin, Same-origin Policy และ CORS

  • URI — แก่น: ตัวระบุ resource; URL เป็น URI ที่ระบุตำแหน่ง/วิธีเข้าถึงตาม scheme
  • URL components — แก่น: scheme://userinfo@host:port/path?query#fragment; fragment ไม่ถูกส่งใน HTTP request ตามปกติ
  • Origin — แก่น: tuple ของ scheme + host + port; path ไม่ใช่ส่วน origin
  • Same-origin Policy — แก่น: browser จำกัด script จาก origin หนึ่งอ่าน/จัดการ resource ของอีก origin
  • CORS — แก่น: กลไก response headers ให้ server opt in ว่า origin ใดอ่าน response ผ่าน browser ได้
  • Simple request — แก่น: บาง method/header/content type ส่งตรงและตรวจ CORS ที่ response
  • Preflight — แก่น: browser ส่ง OPTIONS ถาม permission ก่อน request บางชนิด
  • Credentials — แก่น: cookie/client credential ต้องตั้งทั้งฝั่ง request และ server อย่างเจาะจง; wildcard origin ใช้ร่วม credential ไม่ได้ตามรูปแบบทั่วไป

CORS ไม่ใช่ authentication, authorization, firewall หรือการป้องกัน server-to-server request ผู้โจมตียังเรียก API นอก browser ได้ Server ต้องตรวจสิทธิ์ทุก request เอง

HTML Semantics, DOM, Forms และ Progressive enhancement

  • Semantic HTML — หลักที่ถูกต้อง: เลือก heading, nav, main, button, form, label, table ตามความหมายก่อน ARIA
  • DOM — หลักที่ถูกต้อง: tree/object model ของ document ที่ script และ accessibility API ใช้ ไม่ใช่ source HTML เพียงอย่างเดียว
  • Form — หลักที่ถูกต้อง: label เชื่อม control, name ใช้ส่งค่า, type/autocomplete ช่วย input; server validation ยังจำเป็น
  • Button vs link — หลักที่ถูกต้อง: button ทำ action; link นำทางไป resource/URL
  • Progressive enhancement — หลักที่ถูกต้อง: core content/action ใช้ได้ก่อน แล้วเพิ่ม CSS/JavaScript capability
  • Responsive — หลักที่ถูกต้อง: layout/media/container query และ fluid sizing ตามพื้นที่ ไม่ใช่ทำเฉพาะ device รุ่นหนึ่ง
  • Media — หลักที่ถูกต้อง: responsive images, dimensions, lazy loading ตามเหมาะสม, alt text ตามหน้าที่
  • ARIA — หลักที่ถูกต้อง: เสริม semantics/state เมื่อ native element ไม่พอ; ARIA ที่ผิดอาจแย่กว่าการไม่ใส่

Client validation เพิ่ม UX แต่เชื่อถือไม่ได้เพราะ bypass ได้ ข้อมูลทุกช่องทาง—form, JSON, header, file, message—ต้อง validate ตาม schema/business rule ที่ trust boundary

CSS, Layout และ Responsive design

  • Cascade — คำอธิบาย/ข้อควรระวัง: origin, importance, layer, specificity และ source order ร่วมตัดสินค่า
  • Box model — คำอธิบาย/ข้อควรระวัง: content + padding + border + margin; box-sizing เปลี่ยนการคิดขนาด declared box
  • Normal flow — คำอธิบาย/ข้อควรระวัง: block/inline formatting เป็นฐานก่อน position/flex/grid
  • Flexbox — คำอธิบาย/ข้อควรระวัง: layout หนึ่งมิติและกระจาย/จัดแนว item
  • Grid — คำอธิบาย/ข้อควรระวัง: layout สองมิติ row/column และพื้นที่
  • Position — คำอธิบาย/ข้อควรระวัง: static/relative/absolute/fixed/sticky มี containing block/stacking context
  • Responsive units — คำอธิบาย/ข้อควรระวัง: %, rem/em, viewport/container units เลือกตามความสัมพันธ์ที่ต้องการ
  • Media/container query — คำอธิบาย/ข้อควรระวัง: ปรับตาม viewport/media capability หรือขนาด container
  • Design tokens — คำอธิบาย/ข้อควรระวัง: ชื่อเชิง semantic ของ color/spacing/type ช่วย consistency/theming
  • Reduced motion/contrast — คำอธิบาย/ข้อควรระวัง: เคารพ preference และรักษา focus/contrast/zoom

อย่าแก้ responsive ด้วย breakpoint จำนวนมากก่อนจัด content hierarchy และ intrinsic layout; ทดสอบ keyboard, zoom, long text, localization และหน้าจอหลายขนาด

JavaScript Runtime, Event loop และ Async

  • Call stack — แก่น: รัน JavaScript job ตามลำดับใน execution context
  • Heap — แก่น: พื้นที่ object/memory ที่ garbage collector จัดการ
  • Web/host APIs — แก่น: timer, network, DOM, storage ไม่ใช่ทุกอย่างในภาษา ECMAScript เอง
  • Task/macrotask — แก่น: เช่น event/timer บางชนิดเข้าสู่ task queue
  • Microtask — แก่น: promise reaction/queueMicrotask ถูก drain ก่อน render/next task ตาม event-loop rules
  • Promise — แก่น: ตัวแทน eventual completion/failure; ไม่ทำให้ CPU work ขนานเอง
  • async/await — แก่น: syntax บน Promise; await yield continuation ไม่ block thread ทั้ง process
  • Race condition — แก่น: ผลขึ้นกับ timing ของงาน async/shared state
  • Abort/cancellation — แก่น: ยกเลิก fetch/work เมื่อไม่ต้องการ ลด stale response/resource waste
  • Web Worker — แก่น: แยก thread/context สำหรับ CPU work; สื่อสารด้วย message/transfer

ข้อผิดพลาดที่พบบ่อยคือ await แบบอนุกรมโดยไม่จำเป็น, Promise ไม่ catch, update state หลัง component ถูกทิ้ง, stale closure, งาน CPU หนักค้าง main thread และ retry โดยไม่มีขอบเขต

Rendering: CSR, SSR, SSG, Hydration และ Streaming

  • CSR — เกิดอะไร: browser fetch JS/data แล้วสร้าง UI; เหมาะ/ข้อแลกเปลี่ยน: interaction สูง; initial JS/SEO/accessibility/loading state ต้องดู
  • SSR — เกิดอะไร: server render HTML ต่อ request; เหมาะ/ข้อแลกเปลี่ยน: personalized/fresh; server cost/cache/latency/hydration
  • SSG — เกิดอะไร: render ล่วงหน้าตอน build; เหมาะ/ข้อแลกเปลี่ยน: เนื้อหาคงที่/เสิร์ฟเร็ว; freshness/build scale
  • Incremental regeneration — เกิดอะไร: rebuild/revalidate บาง page หลัง deploy; เหมาะ/ข้อแลกเปลี่ยน: สมดุล freshness กับ static delivery; stale window
  • Hydration — เกิดอะไร: ผูก behavior/client state เข้ากับ server-rendered markup; เหมาะ/ข้อแลกเปลี่ยน: markup/state/time ไม่ตรงทำ mismatch
  • Streaming SSR — เกิดอะไร: ส่ง UI/HTML เป็นส่วนเมื่อพร้อม; เหมาะ/ข้อแลกเปลี่ยน: ลดเวลารอส่วนแรก; error/loading boundary/cache ซับซ้อน
  • Islands/partial hydration — เกิดอะไร: hydrate เฉพาะ interactive islands; เหมาะ/ข้อแลกเปลี่ยน: ลด JS แต่ boundary/data flow ต้องชัด
  • Server component pattern — เกิดอะไร: บาง component render/fetch ฝั่ง server และไม่ส่ง runtime JS ของส่วนนั้น; เหมาะ/ข้อแลกเปลี่ยน: serialization, boundary, framework semantics

เลือก rendering ต่อ route/segment ไม่จำเป็นต้องแบบเดียวทั้งระบบ วัด real-user performance, freshness, personalization, cacheability, development complexity และ failure behavior

API Styles: REST, RPC, GraphQL, SOAP, WebSocket และ SSE

  • RESTful HTTP — จุดเด่น: resource + uniform HTTP semantics + representation/cache; ความเสี่ยง/เหมาะ: boundary/resource/error/version ให้สม่ำเสมอ
  • RPC — จุดเด่น: operation/action ชัดและ generate contract ได้; ความเสี่ยง/เหมาะ: coupling กับ method/schema; HTTP semantics อาจถูกซ่อน
  • GraphQL — จุดเด่น: client เลือก field ผ่าน typed schema endpoint; ความเสี่ยง/เหมาะ: authorization ต่อ field, query cost/N+1/cache complexity
  • SOAP — จุดเด่น: XML envelope, WSDL/contract และ WS-* ecosystem; ความเสี่ยง/เหมาะ: พิธีการ/ขนาดสูงแต่เหมาะ integration ที่ต้อง formal standard
  • WebSocket — จุดเด่น: full-duplex connection ยาว; ความเสี่ยง/เหมาะ: connection state, auth refresh, scaling/backpressure/reconnect
  • SSE — จุดเด่น: server→browser event stream ผ่าน HTTP; ความเสี่ยง/เหมาะ: ทิศเดียว; reconnect/event ID; proxy timeout
  • Webhook — จุดเด่น: provider callback เมื่อ event เกิด; ความเสี่ยง/เหมาะ: signature, replay protection, retry, idempotent receiver
  • Message/queue API — จุดเด่น: async durable integration; ความเสี่ยง/เหมาะ: eventual consistency, duplicate/order/schema evolution

REST เป็น architectural style ไม่ใช่ protocol และไม่เท่ากับ “JSON over HTTP” ทุก API ส่วน SOAP เป็น protocol/message framework ที่มักมี formal contract

หัวข้อ 2

REST/API Contract ที่ใช้งานจริง

  • Resource URI — แนวทาง: ใช้ noun/identity/hierarchy เท่าที่มีความหมาย ไม่ใส่ verb โดยไม่จำเป็น
  • Method/status — แนวทาง: ตรง semantics และแยก sync success จาก accepted async work
  • Representation — แนวทาง: Content-Type/Accept, schema, required/optional/null และ date/number semantics ชัด
  • Validation error — แนวทาง: stable machine code, field/path, safe message และ trace/correlation ID
  • Pagination — แนวทาง: offset/limit ง่ายแต่ drift; cursor/keyset เหมาะชุดใหญ่/เปลี่ยนเร็ว
  • Filtering/sorting — แนวทาง: allowlist field/operator และจำกัด query cost
  • Versioning — แนวทาง: prefer additive compatible change; breaking change มี policy/deprecation/migration
  • Concurrency control — แนวทาง: ETag/If-Match หรือ version field ป้องกัน lost update
  • Idempotency — แนวทาง: dedup key + request fingerprint + result/expiry/atomic record สำหรับ create/payment/retry
  • Rate limiting — แนวทาง: ต่อ principal/resource/risk; ตอบ 429 และ guidance โดยไม่เป็น authorization substitute
  • Documentation — แนวทาง: contract/examples/error/security/SLO/change log; contract test เทียบ implementation

API gateway รวม cross-cutting policy ได้ แต่ business authorization/invariant ยังต้องอยู่ใน service ที่เป็นเจ้าของข้อมูล ห้ามเชื่อ header identity จาก client โดยไม่ผ่าน trusted proxy contract

Reliability: Timeout, Retry, Idempotency และ Resilience

  • Timeout/deadline — หลักใช้: จำกัดเวลาทุก network call และส่ง budget ต่อ dependency; ข้อควรระวัง: default ยาว/ไม่มี timeout ทำ resource ค้าง
  • Retry — หลักใช้: เฉพาะ transient + safe/idempotent operation; exponential backoff + jitter + cap; ข้อควรระวัง: retry storm, duplicate side effect, deadline เกิน
  • Circuit breaker — หลักใช้: หยุดเรียก dependency ที่ล้มชั่วคราวและ probe recovery; ข้อควรระวัง: ไม่แทน timeout/fallback/monitoring
  • Bulkhead — หลักใช้: แยก pool/queue/resource ลด blast radius; ข้อควรระวัง: partition capacity ต้องเหมาะ
  • Backpressure — หลักใช้: ชะลอ/ปฏิเสธ/queue เมื่อ downstream รับไม่ไหว; ข้อควรระวัง: queue ไร้ขอบเขตเพียงย้ายจุดล้ม
  • Load shedding — หลักใช้: ตัดงาน priority ต่ำเมื่อ overload; ข้อควรระวัง: ต้องรักษาความถูกต้องและส่งสถานะชัด
  • Fallback — หลักใช้: ผล degraded/cached/default ที่ยอมรับได้; ข้อควรระวัง: ห้ามคืนข้อมูลผิด/เก่าโดยไม่บอกในงานเสี่ยงสูง
  • Health checks — หลักใช้: liveness แยก readiness; dependency check พอดี; ข้อควรระวัง: check หนักทำระบบพังเพิ่ม
  • Idempotent consumer — หลักใช้: บันทึก processed event/key atomic กับ side effect; ข้อควรระวัง: at-least-once delivery ทำ duplicate ได้

ข้อสรุป “retry ทุก error” ผิด ต้องจำแนก permanent/transient, operation semantics, deadline, attempt budget และ observability

Authentication, Authorization, Session, OAuth และ OIDC

  • Identification — ตอบให้ตรง: ผู้ใช้กล่าวว่าเป็น principal ใด
  • Authentication (AuthN) — ตอบให้ตรง: พิสูจน์ identity/credential
  • Authorization (AuthZ) — ตอบให้ตรง: ตัดสินว่า principal ทำ action กับ resource/context นี้ได้หรือไม่
  • Accounting/Audit — ตอบให้ตรง: บันทึกกิจกรรมที่เพียงพอและตรวจสอบได้ตามนโยบาย
  • Session — ตอบให้ตรง: server-side หรือ distributed state ผูก opaque session ID กับ login/context
  • JWT — ตอบให้ตรง: รูป token format แบบ signed/encrypted ตาม JOSE; payload ของ signed JWT อ่านได้ ไม่ใช่ encryption
  • OAuth 2.0 — ตอบให้ตรง: framework สำหรับ delegated authorization/access token
  • OpenID Connect — ตอบให้ตรง: identity layer บน OAuth 2.0 สำหรับ authentication และ ID token/user info
  • SAML — ตอบให้ตรง: XML-based federation assertion ใน enterprise/SSO หลายระบบ
  • MFA — ตอบให้ตรง: ใช้ปัจจัยต่างประเภทมากกว่าหนึ่ง ลดผล credential เดี่ยวถูกขโมย
  • RBAC — ตอบให้ตรง: สิทธิผ่าน role; จัดการง่ายแต่ role explosion ได้
  • ABAC/policy-based — ตอบให้ตรง: ตัดสินจาก subject/resource/action/environment attributes; ยืดหยุ่นแต่ policy/test ซับซ้อน

Authentication สำเร็จไม่แปลว่ามีสิทธิ์ Server ต้องทำ object/function/field-level authorization ทุก request และตรวจ tenant/ownership จาก trusted identity—not ID ที่ client เปลี่ยนได้

Cookie, Session และ Token Storage อย่างปลอดภัย

  • Session ID — แนวทางและเหตุผล: สุ่มคาดเดายาก, rotate หลัง login/privilege change, revoke/expire และไม่ใส่ข้อมูลลับใน ID
  • Secure — แนวทางและเหตุผล: ส่ง cookie เฉพาะช่องทาง secure
  • HttpOnly — แนวทางและเหตุผล: script อ่าน cookie ไม่ได้ ลดการขโมย token ผ่าน XSS แต่ XSS ยังสั่ง request ใน browser ได้
  • SameSite — แนวทางและเหตุผล: ควบคุม cross-site cookie context ช่วยลด CSRF; เลือก Lax/Strict/None ตาม flow และ Secure เมื่อกำหนด None
  • Domain/Path — แนวทางและเหตุผล: ลด scope เท่าที่ทำได้; ไม่ใช่ security boundary ที่แทน host isolation ทั้งหมด
  • CSRF defense — แนวทางและเหตุผล: SameSite + anti-CSRF token/origin validation ตาม architecture; state-changing GET ผิด semantics
  • Browser storage — แนวทางและเหตุผล: localStorage อ่านได้ด้วย script origin; หลีกเลี่ยง long-lived bearer secret เมื่อ XSS risk สูง
  • Access token — แนวทางและเหตุผล: สั้น, audience/scope จำกัด, validate issuer/signature/time/algorithm และไม่ log
  • Refresh token — แนวทางและเหตุผล: ปกป้องสูง, rotate/reuse detection/revoke ตาม client type
  • Logout — แนวทางและเหตุผล: ยุติ session/revoke credential ที่เกี่ยว; ลบ client value อย่างเดียวอาจไม่พอ

JWT ไม่ได้ “ปลอดภัยกว่า session” โดยตัวมันเอง และ stateless verification อาจทำ revocation/permission freshness ยากขึ้น เลือกตาม trust boundary, client type, scale, revocation และ threat model

OWASP Top 10:2025 — รายการล่าสุดที่ต้องแยกจากปี 2021

  • A01 — หมวด: Broken Access Control; แก่นปัญหา: บังคับ policy/ownership/tenant/function/object ไม่ครบ; รวม SSRF ใน mapping รุ่นนี้; Control หลัก: deny by default, server-side authorization ทุก request, trusted identity, network/URL egress control, test matrix
  • A02 — หมวด: Security Misconfiguration; แก่นปัญหา: default/debug/permission/header/cloud/service/config ไม่ปลอดภัยหรือไม่สม่ำเสมอ; Control หลัก: harden baseline, minimal feature, config-as-code, automated check, secret separation, patch
  • A03 — หมวด: Software Supply Chain Failures; แก่นปัญหา: dependency/build/registry/artifact/update pipeline ถูกแทรกแซงหรือตรวจไม่ครบ; Control หลัก: inventory/SBOM, pin/verify provenance-signature, protect CI, review dependency, rapid remediation
  • A04 — หมวด: Cryptographic Failures; แก่นปัญหา: ไม่เข้ารหัส/เลือก algorithm-key-protocol/lifecycle ผิด; Control หลัก: data classification, modern vetted crypto, TLS, key management/rotation, password hashing, no secret in URL/log
  • A05 — หมวด: Injection; แก่นปัญหา: ข้อมูลไม่เชื่อถือถูก interpreter มองเป็น command/query/template; Control หลัก: parameterization, context-aware output encoding, allowlist/schema, separate code/data, least privilege
  • A06 — หมวด: Insecure Design; แก่นปัญหา: ขาด security requirements, threat model, abuse-case และ control เชิงออกแบบ; Control หลัก: secure design pattern, trust boundary, misuse case, risk review, invariant/rate/resource limit
  • A07 — หมวด: Authentication Failures; แก่นปัญหา: credential/session/recovery/MFA/login control อ่อน; Control หลัก: standard identity, MFA, secure session, rate/credential-stuffing defense, safe recovery, no default credential
  • A08 — หมวด: Software or Data Integrity Failures; แก่นปัญหา: เชื่อ code/data/update/deserialization โดยไม่ verify integrity/trust boundary; Control หลัก: signature/hash/provenance, trusted repository, safe serialization, protected CI/CD, review auto-update
  • A09 — หมวด: Security Logging and Alerting Failures; แก่นปัญหา: event สำคัญไม่ถูก log/normalize/protect/alert/respond; Control หลัก: security event model, tamper resistance, correlation, alert with owner/runbook, retention/privacy และ exercise
  • A10 — หมวด: Mishandling of Exceptional Conditions; แก่นปัญหา: error/edge/resource exhaustion/fail-open/logical condition จัดการผิด; Control หลัก: fail secure, centralized exception boundary, exhaustive state/limit/timeout, rollback/cleanup, chaos/negative test

OWASP Top 10 เป็น awareness document จัดลำดับหมวดความเสี่ยง ไม่ใช่ checklist ที่ทำครบแล้วรับรองความปลอดภัย ใช้คู่ threat modeling, ASVS/ข้อกำหนด, secure SDLC, testing และ operation controls. ข้อมูลเดิมอาจถาม OWASP Top 10:2021 ซึ่งลำดับคือ Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, SSRF ต้องดู “ปี” ในกรณีศึกษาก่อนตอบ

Web Vulnerabilities: แยก Source, Sink และ Control ให้ตรงบริบท

  • SQL/NoSQL/OS/LDAP Injection — เกิดเมื่อ: untrusted input ประกอบภาษาคำสั่ง; การป้องกันหลัก: parameterized API/structured query, allowlist, least privilege; escaping อย่างเดียวเปราะ
  • Stored/Reflected XSS — เกิดเมื่อ: ข้อมูลไม่เชื่อถือออกสู่ HTML/attribute/URL/JS context; การป้องกันหลัก: framework auto-escape + context-aware encoding, sanitize เฉพาะ rich HTML, CSP defense-in-depth
  • DOM XSS — เกิดเมื่อ: client source ไหลเข้าสู่ DOM/code sink เช่น innerHTML/eval; การป้องกันหลัก: safe DOM API, avoid dangerous sink, sanitize Trusted Types/CSP ตามระบบ
  • CSRF — เกิดเมื่อ: browser แนบ ambient credential กับ request ที่ attacker ชักนำ; การป้องกันหลัก: anti-CSRF token, SameSite, origin checks, no unsafe GET, re-auth high risk
  • IDOR/BOLA — เกิดเมื่อ: ใช้ object ID จาก client โดยไม่ตรวจสิทธิ์ resource instance; การป้องกันหลัก: object-level authorization + tenant/ownership filter every access
  • SSRF — เกิดเมื่อ: server fetch URL/host ที่ผู้ใช้ควบคุม; การป้องกันหลัก: destination allowlist, resolve/redirect/IP validation, egress network policy, block metadata/internal ranges
  • Path traversal — เกิดเมื่อ: input ประกอบ filesystem path แล้วหนีฐาน; การป้องกันหลัก: server-generated mapping, canonicalize แล้วตรวจ base, allowlist, least filesystem privilege
  • Unsafe deserialization — เกิดเมื่อ: deserialize type/object graph ที่ไม่เชื่อถือ; การป้องกันหลัก: simple schema formats, type allowlist, integrity, no native object deserialization จาก untrusted
  • Command execution/template injection — เกิดเมื่อ: input เข้าสู่ shell/eval/template expression; การป้องกันหลัก: ไม่เรียก shell, fixed command+arg API, sandbox/allowlist, no dynamic evaluation
  • Open redirect — เกิดเมื่อ: redirect target จาก input ไม่ตรวจ; การป้องกันหลัก: relative target/allowlist, server mapping, warning external link
  • Clickjacking — เกิดเมื่อ: หน้า sensitive ถูก frame หลอก click; การป้องกันหลัก: CSP frame-ancestors และ UI confirmation ตามความเสี่ยง
  • Mass assignment — เกิดเมื่อ: bind request ทุก field เข้าสู่ model; การป้องกันหลัก: DTO/allowlist writable fields + server-owned value
  • Race/business logic abuse — เกิดเมื่อ: หลาย request/replay ข้าม invariant/limit; การป้องกันหลัก: transaction/unique constraint/idempotency/locking/rate/state machine

Input validation ตรวจว่าข้อมูลอยู่ใน domain; output encoding ทำให้ข้อมูลไม่กลายเป็น code ใน output context; sanitization ยอมให้ subset ของ markup; parameterization แยก query code กับ values—ไม่ใช่คำเดียวแทนกัน

Security Headers, TLS, Secrets และ Data Protection

  • Content-Security-Policy — หน้าที่/ข้อควรจำ: จำกัดแหล่ง content/script/connect/frame; nonce/hash และลด unsafe-inline; report ช่วย tune แต่ CSP ไม่แทนแก้ XSS
  • Strict-Transport-Security — หน้าที่/ข้อควรจำ: บอก browser ใช้ HTTPS ต่อ host ตามเวลา; deploy/subdomain/preload ต้องวางแผน
  • X-Content-Type-Options: nosniff — หน้าที่/ข้อควรจำ: ลด MIME sniffing บางบริบท
  • frame-ancestors — หน้าที่/ข้อควรจำ: CSP directive คุมว่าใคร frame หน้าได้; ทดแทน/เหนือกว่า X-Frame-Options ในแนวทางปัจจุบัน
  • Referrer-Policy — หน้าที่/ข้อควรจำ: จำกัดข้อมูล URL/referrer ที่ส่งข้ามปลายทาง
  • Permissions-Policy — หน้าที่/ข้อควรจำ: จำกัด browser features/embedded origins
  • CORS headers — หน้าที่/ข้อควรจำ: อนุญาต browser origin อ่าน response; กำหนดแคบและ Vary: Origin เมื่อ dynamic
  • Secret management — หน้าที่/ข้อควรจำ: ไม่ฝังใน source/image/client bundle/log; ใช้ secret store, short-lived identity, rotate/audit
  • Encryption in transit — หน้าที่/ข้อควรจำ: TLS ระหว่างทุก trust boundary ตาม threat; validate peer/hostname
  • Encryption at rest — หน้าที่/ข้อควรจำ: disk/database/object/key ตาม classification; key แยกและ lifecycle ชัด
  • Password storage — หน้าที่/ข้อควรจำ: salted adaptive password hashing เช่น Argon2id/bcrypt/scrypt ตาม policy—not reversible encryption หรือ plain hash
  • Sensitive data — หน้าที่/ข้อควรจำ: เก็บเท่าจำเป็น, retention/delete, mask log, minimize response/cache, privacy access

Frontend bundle และ environment ที่ฝังตอน build ถูกผู้ใช้ดาวน์โหลดได้ จึงไม่มี “secret ฝั่ง frontend” API key ที่เปิดเผยต้องถูกออกแบบเป็น public identifier พร้อม restriction ไม่ใช่ credential ที่เชื่อถือ

File Upload, Download และ Content Handling

  • Size/count/time — แนวทาง: จำกัดหลายชั้นและ stream แทนโหลดทั้งไฟล์เข้าหน่วยความจำ
  • Filename/path — แนวทาง: สร้างชื่อ storage เอง; เก็บ original เป็น metadata ที่ encode; ป้องกัน traversal/overwrite
  • Type — แนวทาง: allowlist extension + inspect signature/content; Content-Type จาก client เชื่อไม่ได้
  • Malware/active content — แนวทาง: scan/sandbox/quarantine; แยก domain/storage; หลีกเลี่ยง inline execution
  • Image/document transform — แนวทาง: ใช้ patched parser, resource limit และ strip metadata ตาม policy
  • Authorization — แนวทาง: ตรวจ upload/read/delete ต่อ owner/tenant; signed URL อายุสั้นและ scope จำกัด
  • Serving headers — แนวทาง: Content-Disposition, correct Content-Type, nosniff และ CSP/sandbox ตามชนิด
  • Archive — แนวทาง: จำกัด expanded size/file count/path และ recursion ป้องกัน zip bomb/slip
  • Cleanup — แนวทาง: จัดการ partial/orphan/temp และ retention ด้วย job ที่ idempotent
  • Audit — แนวทาง: บันทึก actor/object/result โดยไม่เก็บ sensitive content ใน log

การเปลี่ยนชื่อไฟล์อย่างเดียวไม่ทำให้ไฟล์ปลอดภัย และ antivirus อย่างเดียวไม่ครอบ parser exploit, active HTML/SVG, authorization หรือ resource exhaustion

Software Supply Chain และ Secure SDLC

  1. 1กำหนด security/privacy requirements และ data classification
  2. 2ทำ threat model/abuse case ที่ architecture
  3. 3เลือก/ตรวจ dependency และ provenance
  4. 4secure coding + review + secret scanning
  5. 5SAST/SCA/IaC/container/DAST ตามชั้น
  6. 6signed/immutable artifact และ protected pipeline
  7. 7deploy แบบ least privilege + policy
  8. 8monitor/alert/patch/incident response
  9. 9เรียนรู้และปรับ control
  • Dependency — ใช้เท่าจำเป็น, pin/lock, update ที่ทดสอบ, track transitive และ vulnerability reachability
  • SBOM — บัญชี component/version/provenance ช่วยตอบ incident; ไม่รับรองว่าปลอดภัย
  • CI identity — short-lived scoped credential; branch/review protection และแยก untrusted build
  • Artifact — build reproducible เท่าที่ทำได้, hash/sign/attest และ promote artifact เดิม
  • Environment — แยก dev/test/prod account/data/secret/network; production change audit
  • Patch — inventory + severity/exposure/exploitability + owner/SLA + verify remediation
  • Third party script — ลดจำนวน, CSP/SRI เมื่อเหมาะ, consent/privacy และ outage/failure behavior
  • Incident readiness — runbook, contact, backup/forensic logs, revoke/rotate และ tabletop exercise

WCAG 2.2 และ Accessibility

  • Perceivable — ความหมาย: ผู้ใช้รับรู้ข้อมูลได้หลายรูปแบบ; ตัวอย่าง: text alternative, captions, contrast, reflow/zoom
  • Operable — ความหมาย: ควบคุมได้รวม keyboard/assistive input; ตัวอย่าง: focus visible/order, no keyboard trap, target size, timing control
  • Understandable — ความหมาย: เนื้อหา/navigation/input คาดเดาและแก้ผิดได้; ตัวอย่าง: label/instruction, consistent navigation, error identification/suggestion
  • Robust — ความหมาย: markup/name-role-value ทำงานกับ user agents/assistive tech; ตัวอย่าง: semantic HTML, valid relationships, status message
ระดับความหมายในการอ้าง conformity
Aเกณฑ์พื้นฐานที่ต้องผ่านทั้งหมดสำหรับระดับ A
AAผ่าน A และ AA; เป้าหมายนโยบายที่ใช้บ่อยแต่ต้องดูข้อกำหนดจริง
AAAผ่าน A+AA+AAA; W3C ไม่แนะนำให้บังคับ AAA ทั้งไซต์เป็นนโยบายทั่วไปเพราะบาง content ทำไม่ได้
  • ใช้ native semantic element และ accessible name ที่ถูกก่อน ARIA
  • ทดสอบ keyboard-only, focus, screen reader อย่างน้อยชุดตัวแทน, zoom/reflow, contrast และ automated scan
  • Automated tool จับได้เพียงบางปัญหา ต้องมี manual/user testing
  • Placeholder ไม่แทน label และสีอย่างเดียวไม่ควรเป็นสัญญาณเดียว
  • Dynamic update ต้องจัด focus/status announcement อย่างเหมาะสม
  • Accessibility เป็น requirement ตั้งแต่ design system/content/code/test ไม่ใช่งานท้ายโครงการ

Performance: วัดก่อนแก้และมองทั้ง User journey

  • Network — สิ่งที่วัด/แก้: DNS/TLS/TTFB, compression, cache, request count/priority และ payload
  • Loading — สิ่งที่วัด/แก้: critical resources, image/font strategy, code splitting, lazy load ตาม viewport/intent
  • Main thread — สิ่งที่วัด/แก้: long task, JS parse/execute, render/layout/paint และ third-party script
  • Responsiveness — สิ่งที่วัด/แก้: input/event handler, async work, scheduler, worker และ optimistic UI พร้อม rollback
  • Visual stability — สิ่งที่วัด/แก้: จองขนาด media/ad/dynamic content และหลีกเลี่ยงแทรกเหนือ content
  • Backend — สิ่งที่วัด/แก้: latency percentile, query/N+1, connection pool, cache hit, queue/dependency
  • Capacity — สิ่งที่วัด/แก้: throughput/concurrency/resource saturation และ overload behavior
  • Real user — สิ่งที่วัด/แก้: distribution ตาม device/network/region/route—not ค่าเฉลี่ย lab อย่างเดียว
  • Budget — สิ่งที่วัด/แก้: กำหนด budget ขนาด/เวลา/error และตรวจใน CI/monitoring ตามเหตุผล

Optimization ที่ถูกต้องเริ่มจาก user-impacting bottleneck และ profile/traces ก่อน เช่น ลด N+1 อาจคุ้มกว่าบีบ CSS เล็กน้อย ขณะที่ cache ที่ผิดอาจเร็วแต่คืนข้อมูลผิดหรือรั่ว

Testing Strategy และ Test pyramid ที่ไม่ตายตัว

  • Static/type/lint — ตรวจอะไร: syntax/type/rule/unsafe pattern เร็ว; ข้อจำกัด: ไม่พิสูจน์ runtime/integration ทั้งหมด
  • Unit — ตรวจอะไร: function/class/domain rule แยก dependency; ข้อจำกัด: mock มากอาจพิสูจน์ implementation ไม่ใช่ behavior
  • Component — ตรวจอะไร: UI/component + interaction/accessibility ในขอบเขต; ข้อจำกัด: browser/layout/network จริงอาจต่าง
  • Integration — ตรวจอะไร: module + DB/queue/service adapter จริง; ข้อจำกัด: setup/data/isolation ช้ากว่า
  • Contract — ตรวจอะไร: consumer-provider/schema/compatibility; ข้อจำกัด: ไม่แทน end-to-end/business journey
  • End-to-end — ตรวจอะไร: critical journey ผ่านระบบ; ข้อจำกัด: ช้า/flaky/diagnose ยาก จึงเลือก critical flow
  • Security — ตรวจอะไร: threat test, SAST/SCA/DAST/manual/penetration ตามความเสี่ยง; ข้อจำกัด: tool เดียวไม่ครอบ business logic
  • Performance — ตรวจอะไร: load/stress/spike/soak/capacity และ SLO; ข้อจำกัด: environment/data/workload ต้องสมจริง
  • Resilience — ตรวจอะไร: dependency failure, timeout, retry, failover/chaos; ข้อจำกัด: ต้องมี guardrail และ recovery
  • Accessibility — ตรวจอะไร: automated + keyboard + assistive technology + user test; ข้อจำกัด: automation alone ไม่พอ

Test pyramid เป็น heuristic: มี test เร็ว/เสถียรฐานกว้างและ end-to-end เฉพาะคุณค่า แต่สัดส่วนขึ้นกับ architecture/risk หลีกเลี่ยง ice-cream cone ที่ manual/E2E แพงและ feedback ช้า

องค์ประกอบ Test ที่เชื่อถือได้

  • deterministic เท่าที่ทำได้
  • data/environment แยก
  • assert behavior/contract
  • failure message วินิจฉัยได้
  • ไม่ใช้ sleep แทน condition
  • เก็บ artifact/log/trace เมื่อ fail
  • flaky test มี owner และแก้ ไม่กด rerun จนผ่าน

Observability, Logging และการวินิจฉัย

  • Metrics — ตอบคำถาม: แนวโน้ม/อัตรา/การกระจายเป็นอย่างไร; หลักออกแบบ: counter/gauge/histogram, label cardinality จำกัด, RED/USE ตามชั้น
  • Logs — ตอบคำถาม: เกิด event/decision อะไรพร้อม context; หลักออกแบบ: structured, timestamp, level, service/version, request/trace ID; redact secret/PII
  • Traces — ตอบคำถาม: request ข้าม service ใช้เวลาที่ไหน; หลักออกแบบ: propagate context, span boundary/attributes/error และ sampling
  • Events/audit — ตอบคำถาม: ใครทำอะไรกับ resource เมื่อใดและผลอะไร; หลักออกแบบ: tamper-aware, retention/access และแยกจาก debug log
  • Profiles — ตอบคำถาม: CPU/memory/allocation/lock hotspot อยู่ไหน; หลักออกแบบ: เก็บอย่างปลอดภัยและสัมพันธ์เวอร์ชัน/workload
  • Real-user telemetry — ตอบคำถาม: ผู้ใช้จริงเจอ latency/error/UX ใด; หลักออกแบบ: privacy/consent/sampling และ session correlation ตามนโยบาย
  • SLI — ความหมาย: ตัวชี้วัดบริการ เช่น success rate/latency/freshness/correctness
  • SLO — ความหมาย: เป้าหมายระดับบริการในช่วงเวลา
  • SLA — ความหมาย: ข้อตกลงที่อาจมีผลทางธุรกิจ/กฎหมาย ไม่เท่ากับ SLO
  • Error budget — ความหมาย: ส่วนความไม่น่าเชื่อถือที่ยอมได้จาก SLO ใช้คุมสมดุล change/reliability
  • Alert — ความหมาย: แจ้งอาการที่ต้อง action โดยมี owner/severity/runbook; หลีกเลี่ยง alert noise
  • Incident — ความหมาย: detect→triage→contain→mitigate/recover→communicate→learn
  • Post-incident review — ความหมาย: blameless เชิงระบบ พร้อม action/owner/due/verification

Log ที่ดีไม่ควรบันทึกรหัสผ่าน token session ID เต็ม ข้อมูลส่วนบุคคลเกินจำเป็น หรือ stack trace ต่อผู้ใช้ การ mask ต้องทำก่อนออกจาก trust boundary

CI/CD, Deployment และ Database Change

  1. 1commit ผ่าน review/policy
  2. 2build ครั้งเดียวใน clean environment
  3. 3unit/static/security/dependency test
  4. 4package immutable artifact + provenance
  5. 5integration/contract/E2E ตาม risk
  6. 6deploy พร้อม config/secret แยก
  7. 7health/smoke/telemetry/guardrail
  8. 8promote/canary/rollback หรือ roll-forward
  9. 9บันทึก release และเรียนรู้
  • Rolling — แก่น/ข้อควรระวัง: แทน instance ทีละส่วน; ต้อง backward-compatible ระหว่างหลายเวอร์ชัน
  • Blue–green — แก่น/ข้อควรระวัง: สอง environment สลับ traffic; rollback เร็วแต่ data/schema state ยังต้องคิด
  • Canary — แก่น/ข้อควรระวัง: ส่ง traffic ส่วนน้อยแล้ววัด guardrail ก่อนขยาย
  • Feature flag — แก่น/ข้อควรระวัง: แยก deploy จาก release และทดลองกลุ่ม
  • Shadow — แก่น/ข้อควรระวัง: สำเนา traffic ให้ระบบใหม่โดยไม่ตอบผู้ใช้
  • Rollback — แก่น/ข้อควรระวัง: ย้อน artifact/config ได้
  • Roll-forward — แก่น/ข้อควรระวัง: แก้ version ใหม่เมื่อ rollback เสี่ยง
  • Expand — ตัวอย่าง: เพิ่ม schema/API แบบ compatible เช่น nullable column/dual-read support
  • Migrate — ตัวอย่าง: deploy code ที่รองรับสองแบบ, backfill/dual-write อย่างระวัง, verify
  • Contract — ตัวอย่าง: หลังทุก consumer ย้าย จึงลบ field/table/old path
  • หลัก — ตัวอย่าง: migration idempotent/resumable, lock/time/resource limit, backup/recovery และ monitoring

Container, Cloud และ Shared Responsibility

  • Image — ความหมาย/หลัก: immutable filesystem/package template; scan/minimize/pin base และไม่ใส่ secret
  • Container — ความหมาย/หลัก: process isolation บน host kernel—not VM เต็ม; ตั้ง non-root, resource limit, read-only ตามได้
  • Orchestrator — ความหมาย/หลัก: schedule, service discovery, rollout, health, autoscale/config secret integration
  • VM — ความหมาย/หลัก: virtualized machine/OS แยกกว่าแต่หนักกว่า
  • IaaS — ความหมาย/หลัก: ผู้ใช้ดู OS/runtime/app/data มาก; provider ดู physical/virtual infrastructure
  • PaaS — ความหมาย/หลัก: provider ดู OS/runtime/platform มากขึ้น; ผู้ใช้ยังดู app/config/data/identity
  • SaaS — ความหมาย/หลัก: provider ดำเนิน application; ลูกค้ายังรับผิด account/access/config/data use/integration
  • Managed database/cache/queue — ความหมาย/หลัก: ลดงาน operation บางส่วน ไม่ย้าย ownership ของ schema/query/access/backup objective ทั้งหมด
  • Autoscaling — ความหมาย/หลัก: เพิ่ม/ลด instance ตาม signal; ไม่แก้ slow dependency/data contention และมี lag/cost
  • Infrastructure as Code — ความหมาย/หลัก: version/review/repeatable environment; ต้อง scan drift/secret/state และ protect apply

Cloud ไม่ทำให้ระบบ secure/highly available อัตโนมัติ ต้องออกแบบ region/zone/failure domain, identity/network/data protection, backup/restore, quota/cost และ exit/recovery ตาม requirement

อ่านสรุปฉบับเต็มทุกหัวข้อ
สมาชิก PRO ระบบจะจำหัวข้อที่อ่านค้างไว้ให้ด้วย
PRO 99 บาท/เดือน

เนื้อหาสรุปนี้จัดทำขึ้นเพื่อการศึกษาส่วนบุคคล ห้ามคัดลอก ทำซ้ำ หรือนำไปใช้เพื่อวัตถุประสงค์ทางการค้าโดยไม่ได้รับอนุญาต