สำรวจไลบรารี OAuth ที่เขียนโดย AI ของ Cloudflare

 (neilmadden.blog)
7 คะแนน โดย GN⁺ 2025-06-09 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cloudflare ใช้ Claude LLM ของ Anthropic พัฒนาไลบรารี OAuth ตัวใหม่ และเผยแพร่พรอมป์ต์ที่ใช้ร่วมกันด้วย
  • โครงสร้างโค้ดของไลบรารีดูสะอาดตา แต่ยังมีจุดน่าผิดหวังมากในด้าน การทดสอบและการตรวจสอบความปลอดภัย
  • พบ ทางเลือกที่ไม่เป็นมาตรฐานหรือมีความเสี่ยง ในการตั้งค่า CORS และการรองรับมาตรฐานยืนยันตัวตนบางส่วน
  • แม้งานด้านการเข้ารหัสจะมีจุดแข็ง แต่ก็พบ บั๊กความปลอดภัยร้ายแรง และความเข้าใจคลาดเคลื่อนเกี่ยวกับโปรโตคอล
  • การเขียนโค้ดอัตโนมัติด้วย LLM ช่วยได้ แต่สำหรับ ความปลอดภัยระดับใช้งานจริง ยังจำเป็นต้องมีผู้เชี่ยวชาญตรวจทานอย่างละเอียด

ภาพรวมของไลบรารี OAuth ของ Cloudflare

  • Cloudflare ให้ ไลบรารี OAuth provider ถูกเขียนขึ้นเกือบทั้งหมดแบบอัตโนมัติด้วย Claude LLM ของ Anthropic
  • ผลลัพธ์จาก Claude ได้ผ่าน การตรวจสอบด้านความปลอดภัยและความสอดคล้องตามมาตรฐาน โดยวิศวกร Cloudflare ที่มีประสบการณ์ และยังเปิดเผยกระบวนการโต้ตอบกับ AI อย่างโปร่งใสผ่าน commit history
  • หลังการพัฒนาเวอร์ชันเริ่มต้น ยังมีการใช้พรอมป์ต์เพิ่มเติมกับ Claude และตรวจทานผลลัพธ์เพื่อปรับปรุงคุณภาพ
  • มีการระบุชัดว่าไม่ได้พึ่งพา AI เพียงอย่างเดียว แต่เน้น การตรวจเทียบกับเอกสาร RFC และการรีวิวโดยผู้เชี่ยวชาญหลัก

ความประทับใจแรกของผู้เชี่ยวชาญและการวิเคราะห์โค้ด

  • ตามลักษณะเฉพาะของการเขียนโค้ดด้วย LLM โค้ดถูกรวมอยู่ในไฟล์เดียว เป็นหลัก แต่โครงสร้างยังคงสม่ำเสมอและมีคอมเมนต์ที่ไม่จำเป็นค่อนข้างน้อย
  • แม้จะมีการทดสอบฟังก์ชันการทำงาน แต่ ยังไม่ถึงระดับที่บริการยืนยันตัวตนสำคัญอย่าง OAuth ต้องการ
    • เห็นได้ว่ามีทั้งส่วนที่ขาดการตรวจข้อกำหนดบังคับ (MUST/MUST NOT) และการตรวจความถูกต้องของพารามิเตอร์ที่อ่อนเกินไป

ข้อกังวลด้านความปลอดภัยและคำอธิบายเพิ่มเติมของผู้แปล

1. ปัญหานโยบาย CORS ("YOLO CORS")

  • พบการตั้งค่า CORS header ที่อนุญาตแทบทุก origin จนทำให้ นโยบาย same-origin ถูกยกเลิกไปแทบทั้งหมด
  • ส่วนนี้เป็นสิ่งที่วิศวกร Cloudflare ตัดสินใจเองโดยมนุษย์ ไม่ใช่ LLM
  • แม้จะไม่ได้เปิดใช้ความสามารถ credentials จึงลดความเสี่ยงด้านความปลอดภัยของเบราว์เซอร์แบบร้ายแรงลง แต่ก็ยังขาดความชัดเจนเรื่องสาเหตุและวัตถุประสงค์

2. ไม่มีการใช้ security header มาตรฐาน

  • ใน HTTP response พบว่าไม่มีการใช้ security header สำคัญ เช่น X-Content-Type-Options: nosniff และ HTTP Strict Transport Security
  • แม้บาง header อาจมีความจำเป็นน้อยลงเพราะเป็น JSON API แต่ก็ยังมีเหตุผลมากพอที่จะใช้เพื่อป้องกันช่องโหว่ฝั่ง client/เบราว์เซอร์

3. ร่องรอยของความไม่คุ้นเคยกับมาตรฐาน OAuth

  • มีการรองรับ public client ด้วยการนำวิธี implicit grant ที่ถูกยกเลิกใน OAuth 2.1 กลับมาใช้
    • ที่จริงแล้วฟังก์ชันนี้สามารถทดแทนได้เพียงพอด้วย PKCE หรือการผ่อนคลาย CORS
    • ดูเหมือน Claude จะเป็นผู้แนะนำ implicit grant และในขั้นตอนออก token จริงก็ไม่ได้ตรวจสอบอย่างเหมาะสม
  • การจัดการ Basic Auth ยังไม่สมบูรณ์: ใน OAuth จำเป็นต้องใช้รูปแบบ URL encoding เฉพาะ แต่ส่วนนี้ถูกละไว้
    • อาจก่อให้เกิดบั๊กความปลอดภัยลำดับรองเมื่อ client secret มีเครื่องหมายโคลอนรวมอยู่
    • อย่างไรก็ตาม ไลบรารีนี้สร้าง client ID/secret ขึ้นเอง จึงเป็นโครงสร้างที่ควบคุมรูปแบบได้ในระดับหนึ่ง

4. ปัญหาด้านความปลอดภัยในโค้ดสร้าง token ID

  • วิธีสร้างสตริงสุ่มสำหรับ token ID มี ความเอนเอียงทางสถิติ (biased)
    • แม้ entropy ที่ลดลงอาจทำให้การโจมตีง่ายขึ้น แต่ภัยคุกคามจริงยังมีขอบเขตจำกัด
  • ตรงข้ามกับคำกล่าวอ้างว่า "ทุกบรรทัดของโค้ดได้รับการรีวิวโดยผู้เชี่ยวชาญ" พบว่า บั๊กยังคงอยู่ใน commit แรกเริ่มแบบเดิม
    • ประวัติการที่นักพัฒนาคนหนึ่ง commit ตรงเข้า main branch ถึง 21 ครั้งในวันแรก บ่งชี้ถึงการขาดกระบวนการรีวิวอย่างเป็นระบบ

ความสามารถด้านการเข้ารหัสและตัวอย่างการทำงานร่วมกับ LLM

  • การออกแบบการเข้ารหัสของ token store นั้น มนุษย์เป็นผู้นำ และให้ Claude ช่วยในขั้นตอนลงมือเขียน
  • ใช้วิธีเข้ารหัส props ของแต่ละ token และ wrap symmetric key แยกสำหรับแต่ละ token
  • เมื่อ Claude เสนอการออกแบบที่ผิดพลาดระหว่างทาง วิศวกรได้ อธิบายเจตนาและเป้าหมายด้านความปลอดภัยอย่างชัดเจน เพื่อให้แก้ไข
    • ตัวอย่าง: ชี้ให้เห็นช่องโหว่ที่จะเกิดขึ้นหากใช้แฮช SHA-256 เป็น wrapping key แล้วเปลี่ยนไปใช้แนวทางที่อิง HMAC
    • สำหรับข้อเสนอ PBKDF2 ก็มีการชี้ว่าด้อยประสิทธิภาพด้านสมรรถนะ และปรับไปใช้ HMAC key ขนาด 32 ไบต์
  • กระบวนการนี้แสดงให้เห็นอย่างชัดเจนว่า การทำงานกับ AI ต้องอาศัยความรู้โดเมนในระดับสูง
    • หากไม่ใช่ผู้เชี่ยวชาญ อาจไม่สามารถแม้แต่จะสังเกตเห็นข้อบกพร่องร้ายแรงได้

บทสรุปและนัยสำคัญ

  • แม้จะเป็นเวอร์ชันแรก แต่ คุณภาพโดยรวมถือว่าใช้ได้ อย่างไรก็ตามยังมีความเสี่ยงมากเกินกว่าจะนำไปใช้กับบริการจริงได้ทันที
  • การพัฒนา OAuth provider เป็นงานที่โดยธรรมชาติแล้วต้องการ การตรวจสอบด้านความปลอดภัยและฟังก์ชันที่เข้มงวดมาก
    • โดยทั่วไปมักต้องมีการทดสอบอัตโนมัติระดับหลายแสนรายการและการตรวจความปลอดภัยหลายชั้นในระดับบริษัทใหญ่
    • จึงไม่ใช่สาขาที่สามารถนำการเขียนโค้ดอัตโนมัติด้วย LLM มาใช้ได้อย่าง “ง่ายๆ”
  • commit history ของโปรเจ็กต์นี้แสดงให้เห็นอย่างน่าสนใจว่า LLM สามารถทำหน้าที่เป็นตัวช่วยได้มากแค่ไหน
    • แต่ข้อบกพร่องบางอย่างก็เป็นความผิดพลาดที่ทั้ง LLM และมนุษย์มักทำกันอยู่แล้ว และพบในชุมชนเดิมอย่างคำตอบบน Stack Overflow ด้วยเช่นกัน
    • ในงานโค้ดที่ความละเอียดรอบคอบมีความสำคัญ ทั้ง AI และมนุษย์ต่างต้องใช้ความใส่ใจในรายละเอียดอย่างมาก
  • หากต้องการใช้ LLM เพื่อตรวจโค้ดหรือเชื่อถือผลลัพธ์ที่ได้ ประสบการณ์ลงมือพัฒนาเองและการคิดแบบ System 2 เป็นสิ่งจำเป็น
    • งานที่เรียบง่ายหรือไม่ใช่งานหลักสามารถมอบให้ LLM ได้เพียงพอ แต่ระบบสำคัญที่เกี่ยวข้องกับการยืนยันตัวตนหรือความปลอดภัยควรให้ผู้เชี่ยวชาญเป็นผู้นำการออกแบบและการพัฒนา

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2025-06-09
ความคิดเห็นจาก Hacker News

  • กรณีนี้ทำให้เห็นตรงๆ ว่าเวลาทำงานร่วมกับ LLM ต้องมีความรู้เชิงโดเมนอยู่มาก ตัวอย่างเช่น “ข้อบกพร่องร้ายแรง” ที่ Claude กุขึ้นมากลางทางนั้น นักพัฒนาทั่วไปอาจไม่ทันสังเกต การที่รู้สึกว่าแปลกกับการเปลี่ยนไปใช้ PBKDF2 ก็เป็นเพราะมีความเชี่ยวชาญเฉพาะด้าน สรุปของฉันคือ ถ้าจะใช้ LLM ให้มีประสิทธิภาพ ต้องมีผู้รีวิวที่เก่งและมี “ผู้นำ” คอยกำกับ ถ้าเราไม่รู้เรื่องหัวข้อนั้นมากพอๆ กับ LLM ก็ต้องใช้กับงานที่ไม่สำคัญมาก หรือมีเวลามากพอที่จะตรวจสอบทุกเอาต์พุต

    • ในสภาพแวดล้อมใหม่นี้ ฉันเลยสงสัยว่าผู้เชี่ยวชาญเฉพาะทางจะเกิดขึ้นมาจากที่ไหน สุดท้ายแล้วใครกันที่จะกลายเป็นคนที่รู้ลึกขนาดนั้น

    • ทุกครั้งที่ได้ยินคนพูดว่า "ใช้ LLM เฉพาะในเรื่องที่ตัวเองไม่ค่อยรู้ ถ้าเป็นผู้เชี่ยวชาญก็เขียนโค้ดเอง" ฉันจะงงมาก จริงๆ แล้ว ยิ่งเป็นผู้เชี่ยวชาญก็ยิ่งตรวจทานผลลัพธ์ของ LLM ได้แม่นขึ้น และยิ่งอธิบายสิ่งที่ต้องการในแบบของผู้เชี่ยวชาญโดเมนได้มากเท่าไร ผลลัพธ์ก็ยิ่งดีขึ้นเท่านั้น ซึ่งก็สมเหตุสมผลอยู่แล้ว (เพราะ LLM เป็นเอนจินสร้างข้อความเชิงสถิติ)

    • LLM มีแนวโน้มจะใส่ค่าเริ่มต้น การจัดการ exception และทางอ้อมสารพัดอย่างง่ายดายเกินไป เลยทำให้ได้โค้ดที่ดูเหมือนจะทำงานได้ แต่จริงๆ มีปัญหาหรือพร้อมจะพังในไม่ช้า ใน CLAUDE.md ที่ฉันเขียน ฉันพยายามย้ำจุดนี้หลายครั้ง แต่ก็ยังมักได้ผลลัพธ์แบบนั้นอยู่ดี

    • ฉันใช้ LLM จัดการงาน deploy k8s ไปเกือบทั้งหมด มันให้ผลลัพธ์ที่ใช้งานได้เร็วก็จริง แต่ต้องคอยย้ำตลอดว่าให้ใช้ secret เสมอและอย่า commit ข้อมูลรับรองแบบ plaintext ความผิดพลาดแบบนี้อันตรายมาก ใน tutorial เชิงสอนมักละเรื่องความปลอดภัยเพื่อโฟกัสพื้นฐาน ทำให้ในข้อมูลฝึกของ LLM มีตัวอย่างแบบนั้นเยอะมาก เลยเดาว่ามันถึงสร้างผลลัพธ์ออกมาแบบนี้

    • เมื่อเวลาผ่านไป ฉันคาดหวังว่าเครื่องมือเขียนโค้ด AI จะสามารถค้นคว้าความรู้เชิงโดเมนได้ด้วยตัวเอง ตอนนี้มีเครื่องมือ “AI research” บางตัวที่ทำเรื่องนี้ได้เก่งมากแล้ว แต่ยังไม่ได้รวมเข้ากับเครื่องมือเขียนโค้ดอย่างลงตัว การค้นคว้าอาจอ้างอิงได้ทั้งอินเทอร์เน็ตสาธารณะและความรู้เชิงโดเมนจากเอกสารภายในบริษัท เพียงแต่ความรู้บางส่วนอยู่แค่ในหัวคน จึงยังต้องให้ผู้ใช้ถ่ายทอดให้เอง

  • เมื่อไม่นานมานี้ฉันเขียน Kafka consumer เพื่อทำ data migration โดยมี AI ช่วย ซึ่งเป็นกรณีที่การใช้ AI ได้ผลดีที่สุดเลย: เป็นโปรเจกต์ระยะสั้น เขียนใหม่ตั้งแต่ต้น และฉันรู้ภาษา (go) ค่อนข้างดีแต่ไม่ได้ใช้มานาน ข้อมูลทั้งหมดไหลเข้ามาใน topic เดียว เลยต้องทำ parallel processing ที่ค่อนข้างซับซ้อนเพื่อให้ได้ประสิทธิภาพ โดยรวมแล้วรู้สึกว่า AI ทำให้เร็วขึ้นประมาณ 2 เท่า โดยเฉพาะเวลาลืม syntax ของ go บางอย่าง การถาม AI ตรงๆ ช่วยได้มากกว่าการไปค้นเอง แต่ก็มีบั๊กแฝงอยู่至少 4 จุด (และยังมีบั๊กชัดๆ อีกมาก) ถ้าไม่คุ้นกับ Kafka หรือ multithreading ก็คงเผลอปล่อยขึ้น production ไปแล้ว สำหรับโปรเจกต์ใหญ่หรือระยะยาว การปรับปรุงจะอยู่แถวๆ 10~20% นี่คือแนวโน้มตามโมเดลรุ่นล่าสุด ถ้ามองภาพรวม มันคล้ายกับ productivity gain ตอนเปลี่ยนไปใช้ภาษาที่จัดการหน่วยความจำให้เอง ไม่ได้ใกล้เคียงกับจินตนาการที่ว่า PM จะมาแทนนักพัฒนาเลย (อย่างน้อยจากความเร็วการเปลี่ยนแปลงในช่วง 3 ปีที่ผ่านมา) ที่ฉันกังวลจริงๆ คือ ถ้านักพัฒนาระดับกลางแบบ “เก่งจัด” มีประสิทธิภาพเพิ่มขึ้น 10 เท่าด้วย AI แต่อาจจับหรือรับมือบั๊กละเอียดอ่อนไม่ได้ ก็อาจอันตรายกว่าเดิม วิศวกรระดับ senior/staff น่าจะรับภาระรีวิวถล่มทลายไม่ไหว และยังห่วงด้วยว่าเส้นทางเติบโตจาก junior ไป senior จะเปราะบางขึ้นไหม ตอนนี้โปรแกรมเมอร์สาย copy-paste ก็เป็นปัญหาอยู่แล้ว และ AI ยิ่งทำให้รูปแบบนี้หนักขึ้น สุดท้ายตลาดคงหาทางแก้เอง แต่ก็อดกังวลไม่ได้ว่าอาจต้องใช้เวลาหลายสิบปี

    • บั๊กที่ AI สร้างมันแนบเนียนมาก ฉันเองก็เคยให้ AI เขียนโค้ด multithread แล้วสุดท้ายเอาบั๊กละเอียดอ่อนไปลง production จริงๆ ต่อให้รีวิวและทดสอบแล้ว ก็ยังไม่มีสมาธิแบบเดียวกับตอนลงมือเขียนเองไปทีละบรรทัด ช่วงนี้เลยรู้สึกว่าควรใช้โค้ดที่ AI เขียนเฉพาะในส่วนที่เช็กบั๊กยอดฮิตล่วงหน้าได้ และจำกัดไว้กับพื้นที่ที่ถ้าพังแล้วไม่กระทบร้ายแรง

    • ฉันเองก็รู้สึกว่าใน “งานสำคัญ” ดีขึ้นประมาณ 10~20% เหมือนกัน มันเป็นการเปลี่ยนแปลงจริง แต่ไม่ได้เปลี่ยนแก่นแท้ของการพัฒนาซอฟต์แวร์ ท้ายที่สุดก็เป็นการยืนยันแนวคิดใน "No Silver Bullet" ของ Brooks อีกครั้ง

    • ฉันก็เห็นด้วยกับประเด็น "คนระดับกลางที่เก่งมาก" โดยเฉพาะในสาย consulting ที่โลกความจริงมักมองว่า veteran มีความคุ้มค่าต่อราคาต่ำ เมื่อก่อนฉันก็เป็นคนทำงานเร็วเหมือนกัน และภายหลังก็เหนื่อยกับการต้องอธิบายให้ PM ที่ไม่ใช่สายเทคนิคเข้าใจข้อเสียของวิธีแก้ปัญหาระยะสั้น บริษัท IT ใหญ่ๆ น่าจะจับปัญหาแบบนี้ได้เร็ว แต่ในความเป็นจริง โค้ดที่จัดการข้อมูลการเงินหรือการแพทย์มักถูกเขียนโดยแรงงานสัญญาระยะสั้นราคาถูก สถานการณ์แบบนี้ก็เป็นปัญหามาตั้งแต่ก่อนมี LLM แล้ว ตอนนี้คงเป็นยุคที่หนักหนากว่าเดิมมากสำหรับนักพัฒนาที่อ่อนไหวต่อเรื่องความปลอดภัย

    • มีการพูดถึงการพบบั๊กละเอียดอ่อนในโค้ดที่สร้างขึ้นมา เลยคิดต่อว่าถ้าใช้ AI สร้าง test code เพื่อจับบั๊กเหล่านั้นแบบอัตโนมัติจะเป็นอย่างไร แน่นอนว่า test code เองก็อาจมีบั๊กได้ แต่ก็พอนึกภาพอนาคตที่เราแทบจะรีวิวแค่ผลลัพธ์ของการทดสอบ มากกว่าตัวโค้ดที่สร้างขึ้นมา

    • บอกว่าเป็น parallel processing ที่ซับซ้อน แต่ก็อดสงสัยไม่ได้ว่านี่เป็นปัญหาที่แก้ได้ด้วย partition และ consumer-group หรือเปล่า

  • พอเห็นคนที่เชื่อใจ LLM แบบสุดโต่งและ “ปล่อยตัวตกหน้าผา” ไปกับมันอย่างไม่วิจารณ์อะไรเลยแล้วรู้สึกอึดอัด การพึ่งพา black box แบบเต็มตัว ทั้งให้มันทำงานและตรวจสอบให้เสร็จสรรพ เป็นเรื่องอันตราย แถมโครงสร้างแบบนี้ยังใช้พลังงานมหาศาล และถูกเอาไปใช้เป็นข้ออ้างในการแทนที่คนด้วย เลยพูดตรงๆ ว่ายังไม่ค่อยเชื่อว่าบริบทแบบนี้จะทำให้ชีวิตดีขึ้น 10 เท่า

  • เมื่อเทียบระหว่างการพัฒนาเองกับการตรวจสอบสิ่งที่คนอื่นทำมาให้ (โดยเฉพาะโค้ดจาก LLM) มนุษย์มักถูกหลอกด้วยภาพลักษณ์ที่ดูน่าเชื่อถือ จนยอมรับปัญหาอย่างวิจารณญาณน้อยลง “หน้าตา” ของโค้ดมีผลมากต่อการหาบั๊ก ถ้าอยากพิสูจน์ ก็น่าลองทำการทดลองโดยใส่บั๊กลงไปในโค้ดตั้งใจ แล้วดูว่าผู้รีวิวโค้ดจะหาเจอไหม เวลาเราลงมือ implement อะไรเอง เราจะคิดช้ากว่า ละเอียดกว่า และใส่ใจกับรายละเอียดมากกว่า (จึงทำให้เจอบั๊กที่ไม่คาดคิดด้วย) นี่จึงเป็นเหตุผลที่คนมักแนะนำว่า ถ้าจะเรียนรู้เครื่องมืออะไร ให้ลองเขียน “เวอร์ชันของเล่น” ด้วยตัวเองก่อน เพราะมันเกี่ยวข้องกับโครงสร้างการรับรู้ของมนุษย์

    • ความสามารถในการหาบั๊กละเอียดอ่อนจากโค้ดที่ดูสะอาดเรียบร้อยบนผิวนั้น มาจากความระแวงและความไม่ไว้ใจที่สะสมจากประสบการณ์รีวิวจำนวนมาก ฉันใช้เวลาอยู่กับการรีวิวมานานจนตอนนี้ไม่ว่าโค้ดแบบไหนก็จะสมมติไว้ก่อนว่ามีปัญหาซ่อนอยู่ ถ้าฉันเขียนโค้ดเองบั๊กอาจน้อยลงก็จริง แต่ก็ไม่กล้ารับประกัน เพราะต่อให้เขียนเองฉันก็เคยพลาดโง่ๆ เยอะเหมือนกัน ที่จริงมีโอกาสน้อยด้วยซ้ำที่ฉันจะเป็นคนใช้ไลบรารีนี้เอง (เพราะงานเยอะมาก เลยมักไปตกที่วิศวกร junior) แต่สิ่งหนึ่งที่มั่นใจคือ ต่อให้เป็นโค้ดที่คนเขียน บั๊กก็ไม่ได้หายไปไหน บั๊กหลายตัวที่ Claude สร้างขึ้นมาก็เป็นระดับที่มนุษย์พลาดกันได้ตามปกติ ส่วน ณ ตอนนี้ ฉันไม่คิดว่า Cloudflare จะมาแทนที่นักพัฒนาด้วย LLM การจ้างคนเพิ่มไม่ได้ขึ้นกับปริมาณงาน แต่ขึ้นกับงบประมาณ ถ้า LLM ช่วยเพิ่ม productivity ได้ ก็อาจนำไปสู่รายได้ที่สูงขึ้น และสร้างวงจรให้จ้างคนเพิ่มได้ (แน่นอนว่านี่เป็นความเห็นส่วนตัว ไม่ใช่จุดยืนอย่างเป็นทางการของบริษัท)

  • ในบทความบอกว่าไม่มีคอมเมนต์ที่ไม่จำเป็นมากนัก แต่ในโค้ดจริงมีคอมเมนต์อย่าง // Get the Origin header from the request ซึ่งไม่มีความหมายอะไรเลย

    • คอมเมนต์แบบนี้เป็นหลักฐานชัดเจนว่าใช้ LLM เพราะไม่มีประโยชน์อะไร ฉันลบทิ้งตลอด

    • สำหรับคน คอมเมนต์แบบนี้ไม่มีประโยชน์ แต่เดาว่าสำหรับ LLM การมีคำอธิบายภาษาธรรมชาติของโค้ดด้านล่างแนบมาด้วย อาจทำหน้าที่คล้าย Rosetta Stone ที่ช่วยให้เข้าใจได้ดีขึ้น แม้จะแลกกับการใช้โทเคนมากขึ้นก็ตาม ที่จริงก็อยากทดสอบเหมือนกันว่า LLM จะ edit โค้ดได้ดีขึ้นจริงไหมเมื่อโค้ดมีคอมเมนต์เยอะเกินไป

    • ขอแชร์ประสบการณ์ว่า Claude มีแนวโน้มจะเขียนคอมเมนต์ไร้ประโยชน์และซ้ำซ้อนแบบนี้บ่อยมากจริงๆ

  • สิ่งที่อยากเสนอคือ ลอง freeze branch หนึ่งของโค้ดไว้ แล้วใช้ AI ฝั่งหนึ่งพยายามสร้างและซ่อนช่องโหว่ ส่วนอีกฝั่งพยายามหาและแก้ไขมัน เป็นการทดลองแบบ battle กันของ AI หรือพูดอีกอย่างคือ เอาวิวัฒนาการแบบหมากรุกมาประยุกต์กับการพัฒนาโค้ด

  • ฉันคือคนที่เขียนไลบรารีนี้เอง (ให้แม่นคือคนเขียนพรอมป์ต์) แม้จะไม่ใช่ผู้เชี่ยวชาญ OAuth ระดับเดียวกับ Neil แต่ก็รู้เรื่องนี้พอสมควร และดีใจมากที่เขามารีวิวโค้ดให้ เรื่อง “YOLO CORS” มีความเข้าใจผิดอยู่ มันไม่ใช่ความผิดพลาดแบบมือใหม่ธรรมดา การตั้งค่า CORS นี้ถูกคิดมาอย่างรอบคอบและตั้งใจทำ เราปิดการใช้งาน CORS เฉพาะที่ endpoint ของ OAuth API (การแลก token, การลงทะเบียน client) และ endpoint ของ API ที่ต้องใช้ OAuth bearer token เท่านั้น เพราะ endpoint เหล่านี้ไม่ได้ยืนยันตัวตนด้วยข้อมูลรับรองของเบราว์เซอร์ (เช่น cookie) จึงมองว่า CORS ไม่ได้ปกป้องอะไรอยู่จริง แก่นของ CORS คือเป็นเกราะความปลอดภัยที่ไม่แนบข้อมูลรับรองอัตโนมัติ แต่ bearer token ต้องให้ client แนบมาอย่างชัดเจนอยู่แล้ว จึงปลอดภัยแม้จะข้าม origin ที่จริงฉันเคยโต้เถียงกับผู้เขียนสเปก CORS มาตั้งแต่ก่อนแล้ว โดยยืนกรานว่าการใช้ bearer token แทนข้อมูลรับรองของเบราว์เซอร์คือวิธีที่ปลอดภัยจริง ส่วนประเด็นที่ว่าการสร้าง token ID ไม่มีประสิทธิภาพนั้น ฉันไม่คิดว่าถึงขั้น “ร้ายแรง” ตัวความปลอดภัยเองไม่มีปัญหา และอัลกอริทึมก็เปลี่ยนทีหลังได้อิสระ ที่ commit ของคนคนเดียวขึ้น main 21 ครั้งในวันเดียว เป็นเพราะการ rewrite git history ทำให้วันที่บน github แสดงเพี้ยนไป ขอบคุณมากสำหรับคำชมเรื่องการอิมพลีเมนต์การเข้ารหัส อันนั้นไม่ได้มาจาก AI แต่เป็นเพราะฉันให้คำสั่งด้านการออกแบบไว้อย่าง explicit

    • ที่บอกว่า "ปิด CORS header ใน OAuth API" ความจริงคือกำหนด CORS header เพื่อปิดกฎ CORS ในเชิงบริบทก็พอเข้าใจได้อยู่ แต่เติมคำอธิบายไว้หน่อยเผื่อทำให้สับสน

    • สงสัยว่า Cloudflare มีแผนจะใช้ไลบรารีนี้ใน production จริงหรือไม่

  • พอคิดว่าแม้แต่คำตอบยอดนิยมบน Stack Overflow ก็มีความผิดพลาดแบบเดียวกันเยอะ และ Claude เองก็คงเรียนมาจากที่นั่น ก็อดกังวลไม่ได้ สิ่งที่น่ากลัวกว่าช่องโหว่หรือความผิดพลาดเฉพาะจุด คือคลังความรู้ของสังคมโดยรวมอาจถูกตรึงไว้กับคำตอบยอดนิยมบนอินเทอร์เน็ตยุคก่อน LLM

    • ฉันก็กังวลเหมือนกัน ถ้าบริการบางตัวที่ใช้อยู่ประกาศชัดๆ ต่อสาธารณะว่า “เราไม่ใช้ LLM ในการเขียนโค้ด” มันจะกลายเป็นจุดสร้างความเชื่อมั่นอย่างมาก

  • เห็นว่า ForgeRock มีบั๊กความปลอดภัยใน OAuth implementation เป็นร้อยจุด ทั้งที่ผ่าน automated test หลายแสนรายการ, threat modeling, SAST/DAST ระดับสูงสุด และ expert review มาแล้ว ก็ยิ่งรู้สึกว่า OAuth นั้นยากจริงๆ บางคนถึงกับเรียก implementation ลักษณะนี้ว่าเหมือนไฟไหม้กองขยะ แต่เอาจริงฉันเองก็ไม่เคยอ่านสเปกหรือ implement มันเลย

    • ทุกครั้งที่เคยมีส่วนเกี่ยวข้องกับการ implement OAuth ก็รู้สึกเสมอว่ามันซับซ้อนจนน่ากลัว

    • OAuth นี่น่าปวดหัวจริงๆ และมีมุมเฉพาะทางยิบย่อยเยอะเกินไป

    • ที่จริงโค้ดที่เขียนใหม่ย่อมมีบั๊กเสมอ ยิ่งซับซ้อนก็ยิ่งแน่นอน นั่นจึงเป็นเหตุผลที่บริษัทต่างๆ พยายามใช้โค้ดและเครื่องมือที่ battle tested หรือผ่านสนามจริงมาแล้ว พักเรื่องตลกไว้ก่อน วิธีที่ Anthropic ใช้ generative AI ของตัวเองกับโค้ดภายในอย่างใช้งานได้จริงก็น่าสนใจดี สงสัยว่าจะเอาไปใช้กับ MCP authentication API ในอนาคตด้วยไหม

    • คำว่า “การทดสอบหลายแสนรายการ” ฟังดูเหมือนจะเป็นการโตเชิงปริมาณอย่างเดียว หรือไม่ก็สงสัยว่าอาจเป็นสิ่งที่ LLM สร้างขึ้นตรงๆ แล้วจริงๆ ใครเป็นคนดูแลสิ่งนั้นกันแน่ก็ชวนสงสัย

  • สงสัยว่าเทรนด์การ commit พรอมป์ต์ของตัวเองลง git จะกลายเป็นเรื่องปกติไหม หรือแค่มีลักษณะเป็น showcase เท่านั้น

    • เหตุผลที่ฉัน commit พรอมป์ต์ลงไป ก็เพราะการได้เห็นตรงๆ ว่า LLM สร้างผลลัพธ์อะไรจากพรอมป์ต์แบบนั้น เป็น insight ที่ใหญ่มาก คิดว่าคนอื่นก็น่าจะสนใจเหมือนกัน และก็เป็นอย่างนั้นจริงๆ อนึ่ง ฉันเองก็ไม่รู้วิธีเขียนพรอมป์ต์ให้ “ดี” หรอก แค่เขียนแบบธรรมชาติ เหมือนที่ใช้คุยกับคน แล้วมันก็ดูเหมือนจะเวิร์กดี