นักพัฒนาต้องแบกรับความกดดันจากกำหนดการส่งมอบงาน (sprint deadlines) และการขอเพิ่มฟีเจอร์ใหม่ๆ อยู่เสมอ การปรับจูนประสิทธิภาพ (Performance tuning) และการขัดเกลา UI มักจะเป็นสิ่งที่ได้รับคำชม ในขณะที่เรื่องความปลอดภัยมักจะถูกทิ้งไว้ใน backlog และรอคิวอย่างเงียบเชียบ การรอคอยนั้นคือความผิดพลาด บอทอัตโนมัติจะสแกนอินเทอร์เน็ตตลอด 24 ชั่วโมง เพื่อค้นหาคีย์ที่หลุดรอด จุดที่สามารถทำ injection ได้ และช่องโหว่ในการยืนยันตัวตน การรั่วไหลของข้อมูลกลายเป็นเรื่องปกติในข่าวเทคโนโลยี แต่สำหรับทีมที่ต้องรับผิดชอบ การตามล้างตามเช็ดนั้นเป็นเรื่องที่หนักหนาสาหัสมาก ข่าวดีก็คือ การเขียนโค้ดให้ปลอดภัยไม่จำเป็นต้องจบปริญญาเอกด้านวิทยาการรหัสลับ (cryptography) แต่มันต้องการการสร้างนิสัยที่แข็งแกร่งเพียงไม่กี่อย่างให้กลายเป็นส่วนหนึ่งของเวิร์กโฟลว์ในแต่ละวันของคุณ และนี่คือ 5 แนวทางปฏิบัติที่จะช่วยปกป้องผู้ใช้และระบบของคุณได้อย่างแท้จริง

Secure Your Authentication

หลายทีมมักจะถูกล่อใจให้สร้างระบบล็อกอินขึ้นมาใช้เอง มีทั้งตาราง users, คอลัมน์ password และตัวสร้าง JWT มันดูเหมือนจะง่าย จนกระทั่งคุณตระหนักว่าตอนนี้คุณต้องรับผิดชอบทั้งการจัดการ session, การหมุนเวียน token (token rotation), การป้องกัน brute-force และการรีเซ็ตรหัสผ่านที่ปลอดภัย ทีมส่วนใหญ่ควรหยุดสร้างสิ่งเหล่านี้ขึ้นมาเองตั้งแต่ต้น การส่งต่อหน้าที่การยืนยันตัวตนให้กับผู้ให้บริการอัตลักษณ์ (identity providers) ที่น่าเชื่อถือผ่าน OAuth 2.0 หรือ OpenID Connect จะช่วยลดความเสี่ยงในหลายๆ ด้านออกจากโค้ดของคุณ คุณจะได้ใช้โปรโตคอลที่ผ่านการทดสอบจริงโดยวิศวกรหลายพันคนและได้รับการตรวจสอบจากชุมชนความปลอดภัยในวงกว้าง

อย่างไรก็ตาม หากคุณจำเป็นต้องจัดการรหัสผ่านด้วยตัวเอง จงให้ความสำคัญกับมันอย่างสูงสุด แฮช (Hash) รหัสผ่านทุกตัวโดยใช้ bcrypt หรือ Argon2 อัลกอริทึมเหล่านี้ถูกออกแบบมาให้ทำงานช้าโดยตั้งใจ เพื่อชะลอการทำงานของผู้โจมตีที่ขโมยฐานข้อมูลของคุณไปและพยายามจะถอดรหัสผ่านแบบ offline อย่าทิ้งรหัสผ่านไว้ในรูปแบบ plain text เป็นอันขาด ไม่ว่าจะเป็นใน logs, ในรายงานการแครช (crash reports) หรือที่ไหนก็ตาม

การยืนยันตัวตนแบบหลายปัจจัย (Multi-factor authentication) ไม่ใช่ทางเลือกอีกต่อไป เพราะรหัสผ่านสามารถหลุดได้ และการทำ phishing ก็ได้ผลเสมอ ปัจจัยที่สอง ไม่ว่าจะเป็นแอป TOTP หรือ hardware key จะช่วยลดอัตราการถูกยึดบัญชี (account takeover) ได้อย่างมหาศาล

เมื่อคุณออก session tokens หรือ JWTs ให้เก็บพวกมันไว้ใน HttpOnly และ Secure cookies flag HttpOnly จะช่วยป้องกันไม่ให้ JavaScript อ่านคุกกี้ได้ ซึ่งเป็นการสกัดกั้นการโจมตีแบบ cross-site scripting ได้หลายรูปแบบ ส่วน flag Secure จะช่วยให้แน่ใจว่าเบราว์เซอร์จะส่งคุกกี้ผ่าน HTTPS เท่านั้น อย่าเก็บ JWT ไว้ใน localStorage แม้มันจะดูสะดวก แต่หากไซต์ของคุณมีช่องโหว่ XSS เพียงจุดเดียว ผู้โจมตีจะสามารถเข้าถึง token ของผู้ใช้ได้ทันที

Treat the OWASP Top 10 as Your Baseline

OWASP Top 10 ไม่ใช่แค่หลักสูตรสอบทฤษฎี แต่มันคือรายการวิธีที่พบบ่อยที่สุดที่เว็บแอปพลิเคชันถูกโจมตีจริง การเพิกเฉยต่อมันก็เหมือนกับการเมินป้ายจราจรเพียงเพราะคุณมั่นใจในปฏิกิริยาตอบโต้ของตัวเอง

SQL injection ยังคงตามหลอกหลอนฐานข้อมูลในระบบจริง แม้จะผ่านมาหลายทศวรรษหลังจากที่มีการบันทึกไว้ครั้งแรก วิธีแก้ไขนั้นง่าย แต่ต้องอาศัยวินัย อย่ารวม user input เข้ากับ query string โดยตรง ให้ใช้ parameterized queries หรือ ORM อย่าง Prisma ที่จัดการเรื่องการ escaping ให้คุณ ตัวขับเคลื่อนฐานข้อมูล (database driver) จะแยกโค้ดออกจากข้อมูล ดังนั้น input ที่เป็นอันตรายจึงไม่สามารถเขียนตรรกะของ query ใหม่ได้

Cross-site scripting หรือ XSS มักเกิดขึ้นจากการที่ไม่ได้กรอง user input หากแอปพลิเคชันของคุณมีการแสดงผลข้อมูลใดๆ ที่ผู้ใช้ส่งมา คุณต้องทำการ sanitize ข้อมูลนั้นก่อนเสมอ เฟรมเวิร์กสมัยใหม่มักจะทำการ escape output ให้โดยอัตโนมัติ แต่ custom components หรือ API ในรูปแบบ dangerouslySetInnerHTML อาจข้ามผ่านระบบป้องกันเหล่านั้นได้ ดังนั้นจงระบุให้ชัดเจนว่าคุณเชื่อถือข้อมูลส่วนไหน

Cross-site request forgery (CSRF) คือการหลอกล่อให้เบราว์เซอร์ดำเนินการบางอย่างที่ไม่ควรทำ คุณสามารถบรรเทาปัญหานี้ได้ด้วยการใช้ anti-CSRF tokens ฝังไว้ในฟอร์ม และตั้งค่า attribute SameSite ในคุกกี้ของคุณ การตั้งค่า SameSite=Lax หรือ Strict จะบอกให้เบราว์เซอร์ระงับการส่งคุกกี้ระหว่างการร้องขอแบบ cross-origin ซึ่งจะช่วยหยุดการโจมตี CSRF ส่วนใหญ่ได้อย่างเด็ดขาด

Apply the Principle of Least Privilege

ไม่ใช่ผู้ใช้ทุกคนที่ต้องการสิทธิ์ admin และไม่ใช่ทุก microservice ที่ต้องการสิทธิ์ root ในการเข้าถึงฐานข้อมูล หลักการ "สิทธิ์ขั้นต่ำที่จำเป็น" (Principle of Least Privilege) หมายถึงการมอบสิทธิ์การเข้าถึงเท่าที่จำเป็นสำหรับงานเฉพาะอย่างเท่านั้น และไม่ให้เกินไปกว่านั้น

เริ่มต้นที่ user ของฐานข้อมูลแอปพลิเคชันของคุณ หาก backend ของคุณต้องการเพียงแค่การอ่านและเขียนข้อมูลในแถว (rows) ให้ลบสิทธิ์ในการ drop tables, alter schemas หรือสร้างฐานข้อมูลใหม่ทิ้งไป เมื่อผู้โจมตีเจาะเข้าแอปพลิเคชันของคุณได้ สิทธิ์ที่ถูกจำกัดเหล่านี้จะกลายเป็นกำแพงป้องกัน พวกเขาอาจขโมยข้อมูลได้ แต่จะไม่สามารถล้างโครงสร้างพื้นฐาน (infrastructure) ของคุณทิ้งได้ด้วยคำสั่งเพียงคำสั่งเดียว

ใช้แนวคิดเดียวกันนี้กับสภาพแวดล้อมบนคลาวด์ของคุณ โดยกำหนดขอบเขตของ AWS IAM roles, Google Cloud service accounts และ Azure managed identities ให้จำกัดอยู่เพียงการทำงานเฉพาะอย่างเท่านั้น CI/CD pipeline ที่ทำหน้าที่เพียงแค่ deploy static assets ไม่จำเป็นต้องมีสิทธิ์ในการสร้าง compute clusters ที่มีราคาแพง จงตรวจสอบสิ่งเหล่านี้