คำนำ
ในรูปแบบการพัฒนาของการแยกส่วนหน้าและแบ็คเอนด์การเปลี่ยนแปลงที่ชัดเจนที่สุดในแง่ของบทบาทและฟังก์ชั่นการพัฒนาคือ: ในอดีตนักเรียนส่วนหน้าที่รับผิดชอบการพัฒนาในสภาพแวดล้อมของเบราว์เซอร์ที่จำเป็นในการสำรวจระดับเซิร์ฟเวอร์และรหัสเซิร์ฟเวอร์ และคำถามพื้นฐานก่อนหน้านี้คือวิธีการตรวจสอบความปลอดภัยของเว็บ?
บทความนี้เสนอวิธีแก้ไขปัญหาความปลอดภัยที่พบโดยโหมดการแยกส่วนหน้าและส่วนหลังในการพัฒนาเว็บของส่วนหน้ารวมถึงการตอบโต้และข้อควรระวัง
การป้องกันการโจมตีสคริปต์ข้ามไซต์ (XSS)
ปัญหาและการแก้ปัญหา
การเขียนสคริปต์ข้ามไซต์ (XSS, สคริปต์ข้ามไซต์) เป็นวิธีที่พบบ่อยที่สุดและพื้นฐานที่สุดในการโจมตีเว็บไซต์ ผู้โจมตีสามารถเผยแพร่ข้อมูลที่มีรหัสรุกบนหน้าเว็บ เมื่อเบราว์เซอร์เห็นหน้าเว็บนี้สคริปต์เฉพาะจะถูกดำเนินการเป็นตัวตนและสิทธิ์ของผู้ใช้เบราว์เซอร์ XSS สามารถแก้ไขได้ง่ายขึ้นการขโมยข้อมูลผู้ใช้ข้อมูลผู้ใช้และทำให้เกิดการโจมตีประเภทอื่น ๆ เช่นการโจมตี CSRF
วิธีพื้นฐานในการป้องกันการโจมตี XSS คือการตรวจสอบให้แน่ใจว่าเอาต์พุตข้อมูลใด ๆ ไปยังหน้า HTML จะถูกหลบหนีใน HTML (HTML Escape) ตัวอย่างเช่นรหัสแม่แบบต่อไปนี้:
การคัดลอกรหัสมีดังนี้:
<textarea name = "คำอธิบาย"> $ คำอธิบาย </textarea>
คำอธิบาย $ ในรหัสนี้เป็นตัวแปรของเทมเพลต (ไวยากรณ์ของตัวแปรที่กำหนดในเทมเพลตที่แตกต่างกันนั้นแตกต่างกันนี่เป็นเพียงไดอะแกรม) ข้อมูลที่ส่งโดยผู้ใช้สามารถป้อนส่วนของรหัสที่มี "JavaScript" เพื่อให้ผลลัพธ์ของคำสั่งเทมเพลตข้างต้นกลายเป็นผลลัพธ์ต่อไปนี้:
การคัดลอกรหัสมีดังนี้:
<textarea name = "คำอธิบาย">
</textarea> <script> Alert ('Hello') '</script>
</textarea>
รหัสข้างต้นที่แสดงในเบราว์เซอร์จะเรียกใช้รหัส JavaScript และแจ้งเตือน Hello บนหน้าจอ แน่นอนรหัสนี้ไม่เป็นอันตราย แต่ผู้โจมตีสามารถสร้าง JavaScript เพื่อแก้ไขข้อมูลผู้ใช้หรือขโมยข้อมูลคุกกี้
การแก้ปัญหานั้นง่ายมากซึ่งคือ HTML หลบหนีค่าของ $ คำอธิบาย รหัสเอาต์พุตหลังจากการหลบหนีมีดังนี้
การคัดลอกรหัสมีดังนี้:
<textarea name = "คำอธิบาย">
</textarea> <script> Alert (สวัสดี!) </script>
</textarea>
รหัส HTML ที่หลบหนีข้างต้นไม่เป็นอันตราย
ทางออกของ Midway
หลบหนีข้อมูลเอาต์พุตของผู้ใช้ทั้งหมดในหน้า
มีหลายสถานการณ์และวิธีการในการหลบหนีข้อมูล:
1. หลบหนีโดยใช้กลไกที่ให้ไว้ภายในเทมเพลต
Midway ใช้ kissy xtemplate เป็นภาษาเทมเพลต
ในการใช้งาน XTEMPLATE ข้อมูลเทมเพลตคือไวยากรณ์ที่แยกวิเคราะห์โดยใช้วงเล็บสองตัว ({{val}}) โดยค่าเริ่มต้นข้อมูลจะถูกหลบหนี HTML เพื่อให้นักพัฒนาสามารถเขียนเทมเพลตเช่นนี้:
การคัดลอกรหัสมีดังนี้:
<textarea name = "คำอธิบาย"> {{คำอธิบาย}} </textarea>
ใน XTEMPLATE หากคุณไม่ต้องการให้ข้อมูลเอาต์พุตถูกหลบหนีคุณต้องใช้วงเล็บสามตัว ({{{val}}})
2. ฟังก์ชั่นการหลบหนีอย่างไม่น่าสงสัยในมิดเวย์
นักพัฒนาสามารถเรียกใช้วิธีการหลบหนี HTML โดยตรงโดย Midway ในโปรแกรม Node.js หรือแม่แบบเพื่อหลบหนีข้อมูลที่แสดงดังต่อไปนี้:
วิธีที่ 1: HTML Escape Data ในโปรแกรม node.js
การคัดลอกรหัสมีดังนี้:
VAR Security = ต้องการ ('ความปลอดภัยในช่วงกลาง');
// data จากเซิร์ฟเวอร์เช่น {html: '</textarea>', อื่น ๆ : ""}
data.html = security.escapehtml (data.html);
xtpl = xtpl.render (ข้อมูล);
วิธีที่ 2: HTML Escape HTML Data ในเทมเพลต
การคัดลอกรหัสมีดังนี้:
<textarea name = "คำอธิบาย"> security.escapehtml ({{{คำอธิบาย}}}) </textarea>
หมายเหตุ: Security.escapehtml ใช้สำหรับการหลบหนีเฉพาะเมื่อข้อมูลไม่ได้หลบหนีภายในเทมเพลต มิฉะนั้นเทมเพลตภายในและโปรแกรมจะหลบหนีการซ้อนทับสองครั้งส่งผลให้ผลลัพธ์ที่ไม่ตรงกับความคาดหวัง
แนะนำ: หากคุณใช้ XTEMPLATE ขอแนะนำให้ใช้ {{}} ในตัวของเทมเพลตเพื่อหลบหนีโดยตรง หากคุณใช้เทมเพลตอื่น ๆ ขอแนะนำให้ใช้ Security.escapehtml สำหรับการหลบหนี
กรองเอาต์พุตข้อความที่สมบูรณ์จากผู้ใช้ในหน้า
คุณอาจคิดว่า: "จริง ๆ แล้วฉันแค่ต้องการส่งข้อความที่หลากหลายเช่นกระดานข้อความและฟอรัมบางอย่างเพื่อให้ผู้ใช้มีขนาดแบบอักษรสีพื้นหลังและฟังก์ชั่นอื่น ๆ อย่างง่ายฉันควรจัดการกับข้อความที่หลากหลายเพื่อป้องกัน XSS ได้อย่างไร"
1. ใช้ฟังก์ชั่น RichText ที่จัดทำโดย Security ในมิดเวย์
Midway ให้วิธีการ RichText ซึ่งใช้เป็นพิเศษเพื่อกรองข้อความที่อุดมไปด้วยและป้องกันช่องโหว่เช่น XSS, ฟิชชิ่งและการขโมยคุกกี้
มีกระดานข้อความและรหัสเทมเพลตอาจมีดังนี้:
การคัดลอกรหัสมีดังนี้:
<div>
{{{ข้อความ}}}
</div>
เนื่องจากข้อความเป็นข้อมูลอินพุตของผู้ใช้เนื้อหาของบอร์ดข้อความจึงมีข้อมูลข้อความที่หลากหลายที่นี่มีการใช้เครื่องมือจัดฟันสามแบบใน XTEMPLATE และการหลบหนี HTML จึงไม่ได้ดำเนินการตามค่าเริ่มต้น จากนั้นข้อมูลที่ป้อนโดยผู้ใช้มีดังนี้:
การคัดลอกรหัสมีดังนี้:
<script src = "http://eval.com/eval.js"> </script> <span style = "สี: สีแดง; Font-Size: 20px; ตำแหน่ง: แก้ไข;"> ฉันทิ้งข้อความ </span>
หากข้อมูลข้อความที่หลากหลายข้างต้นถูกส่งไปยังหน้าโดยตรงมันจะนำไปสู่การฉีด JS จากไซต์ eval.com ลงในหน้าปัจจุบันอย่างหลีกเลี่ยงไม่ได้ทำให้เกิดการโจมตี XSS เพื่อป้องกันช่องโหว่นี้เราเพียงเรียกใช้วิธีการรักษาความปลอดภัย richtext ในเทมเพลตหรือโปรแกรมเพื่อประมวลผลอินพุตข้อความที่หลากหลายโดยผู้ใช้
วิธีการโทรคล้ายกับ Escapehtml และมีสองวิธีในการ
วิธีที่ 1: โทรโดยตรงในโปรแกรม node.js
การคัดลอกรหัสมีดังนี้:
message = security.richtext (ข้อความ);
var html = xtpl.render (ข้อความ)
วิธีที่ 2: โทรในเทมเพลต
การคัดลอกรหัสมีดังนี้:
<div>
Security.RichText ({{{message}}})
</div>
หลังจากเรียกใช้วิธีการรักษาความปลอดภัย RichText แล้วเอาต์พุตสุดท้ายมีดังนี้:
การคัดลอกรหัสมีดังนี้:
<div>
<span style = "สี: สีแดง; ขนาดตัวอักษร: 20px;"> ฉันทิ้งข้อความ </span>
</div>
จะเห็นได้ว่าก่อน: แท็กสคริปต์ที่จะทำให้เกิดการโจมตี XSS จะถูกกรองออกโดยตรง ในเวลาเดียวกันตำแหน่งแอตทริบิวต์ CSS: แก้ไข; สไตล์ในแท็กสไตล์จะถูกกรอง ในที่สุดข้อความที่มี HTML ที่ไม่เป็นอันตรายคือเอาต์พุต
เรียนรู้เกี่ยวกับวิธีอื่น ๆ เพื่อนำไปสู่การโจมตีของ XSS
นอกเหนือจากการโจมตี XSS ที่เป็นไปได้ในเทมเพลตหน้าแล้วยังมีอีกหลายวิธีในเว็บแอปพลิเคชันที่อาจมีความเสี่ยง
1. ช่องโหว่ในหน้าข้อผิดพลาด
หากไม่พบหน้าเว็บระบบอาจรายงานข้อผิดพลาดไม่พบ 404 ตัวอย่างเช่น: http: // localhost/page/not/found
404 Notfound
หน้า/หน้า/ไม่/พบไม่ได้ exsit
เห็นได้ชัดว่า: ผู้โจมตีสามารถใช้หน้านี้เพื่อสร้างการเชื่อมต่อเช่นนี้ http: // localhost/%3cscript%3Ealert%28%27HELLO%27%29%3C%2FScript%3E และล่อเหยื่อให้คลิก; หากหน้าข้อผิดพลาดไม่หลบหนีตัวแปรเอาต์พุตการแจ้งเตือน <script> ('สวัสดี') </script> ที่ซ่อนอยู่ในการเชื่อมต่อจะถูกดำเนินการ
ใน Express วิธีการส่งหน้า 404 มีดังนี้
Res.Send (404, 'ขออภัยเราไม่พบสิ่งนั้น!')
ที่นี่นักพัฒนาจำเป็นต้องให้ความสนใจกับการจัดการหน้าข้อผิดพลาด (404 หรือสถานะข้อผิดพลาดอื่น ๆ ) หากเนื้อหาที่ส่งคืนของข้อความแสดงข้อผิดพลาดมีข้อมูลเส้นทาง (อันที่จริงมีความแม่นยำมากขึ้นข้อมูลอินพุตของผู้ใช้) คุณต้องดำเนินการ EscapeHTML
ต่อจากนั้นกลไกการรักษาความปลอดภัยของการจัดการข้อผิดพลาดจะเสร็จสิ้นในระดับ Midway Framework
หมายเหตุเพิ่มเติมสำหรับโซลูชั่นมิดเวย์
เครื่องยนต์เทมเพลตอื่น ๆ
Midway รองรับเทมเพลต XTEMPLATE โดยค่าเริ่มต้น แต่อาจรองรับเทมเพลตอื่น ๆ ในอนาคต: เช่นหยกหนวดหนวด EJS ฯลฯ ในปัจจุบันในเทมเพลตกระแสหลักการเริ่มต้นที่หลบหนี
การสนับสนุนอื่น ๆ สำหรับการหลบหนี
นอกเหนือจากเอาต์พุตข้อมูลข้อความปกติและข้อมูลที่สมบูรณ์บนหน้าแล้วบางสถานการณ์ยังรวมถึงสถานการณ์อื่น ๆ ที่อาจต้องใช้หลบหนี Midway ให้วิธีการหลบหนีที่ใช้กันทั่วไปต่อไปนี้เพื่อให้นักพัฒนาใช้:
Escapehtml ตัวกรองอักขระใน HTML ที่ระบุเพื่อป้องกันช่องโหว่ XSS
JSencode JavaScript Escape ของสตริงอินพุต Unicode Escape of Chinese, Single Quotes และ Double Quotes Escape
Escapejson ไม่ได้ทำลายฟังก์ชั่นการหลบหนีของโครงสร้าง JSON และดำเนินการประมวลผล Escapehtml ในชื่อและ Vaule ในโครงสร้าง JSON
Escapejsonforjsvar เป็น jsencode+Escapejson
ตัวอย่างมีดังนี้
การคัดลอกรหัสมีดังนี้:
var jsontext = "{/" <script>/":/" <script>/"}";
console.log (securityutil.escapejson (jsontext)); // {"<script>": "<script>"}
var jsontext = "{/" hello/":/" <script>/"}";
console.log (Securityutil.escapejsonforjsvar (jsontext)); // {/"/u4f60/u597d/":/"<script>/"}
var str = "การแจ้งเตือน (/" hello/")";
console.log (securityutil.jsencode (str)); // alert (/"/u4f60/u597d/")
การป้องกันการโจมตีโดยการร้องเรียนการร้องขอข้ามไซต์ (CSRF)
ปัญหาและการแก้ปัญหา
คำจำกัดความของข้อกำหนด: แบบฟอร์ม: หมายถึงโดยทั่วไปไปยังแบบฟอร์มที่เบราว์เซอร์ใช้เพื่อส่งข้อมูลบนลูกค้า รวมถึงแท็กข้อมูลการส่ง AJAX ข้อมูลการส่งแบบฟอร์ม ฯลฯ แทนที่จะเป็นแท็กฟอร์มเท่ากับ HTML
การปลอมแปลงคำขอข้ามไซต์ (CSRF, การปลอมแปลงคำขอข้ามไซต์) เป็นการโจมตีทั่วไปอีกครั้ง ผู้โจมตีปลอมแปลงคำขอผ่านวิธีการต่าง ๆ และเลียนแบบพฤติกรรมของผู้ใช้ในการส่งแบบฟอร์มดังนั้นจึงบรรลุวัตถุประสงค์ในการแก้ไขข้อมูลของผู้ใช้หรือทำงานเฉพาะ
เพื่อที่จะแกล้งทำเป็นผู้ใช้การโจมตี CSRF มักจะรวมกับการโจมตี XSS แต่วิธีการอื่น ๆ สามารถนำมาใช้: ตัวอย่างเช่นเพื่อชักนำให้ผู้ใช้คลิกที่ลิงค์ที่มีการโจมตี
ความคิดในการแก้ปัญหาการโจมตี CSRF แบ่งออกเป็นสองขั้นตอน
1. เพิ่มความยากลำบากในการโจมตี รับคำขอเป็นเรื่องง่ายที่จะสร้าง ผู้ใช้สามารถเริ่มต้นคำขอประเภท Get-type ได้โดยคลิกที่ลิงค์ คำขอโพสต์ค่อนข้างยาก ผู้โจมตีมักจะต้องใช้ JavaScript เพื่อนำไปใช้ ดังนั้นการตรวจสอบให้แน่ใจว่าแบบฟอร์มแบบฟอร์มหรืออินเทอร์เฟซเซิร์ฟเวอร์ยอมรับการร้องขอการส่งแบบโพสต์ประเภทเท่านั้นสามารถเพิ่มความปลอดภัยของระบบได้
2. รับรองความถูกต้องเพื่อให้แน่ใจว่าคำขอนั้นกรอกแบบฟอร์มหรือเริ่มต้นคำขอและส่งโดยผู้ใช้แทนที่จะปลอมแปลงโดยบุคคลที่สาม
กระบวนการของการปรับเปลี่ยนข้อมูลเว็บไซต์ผู้ใช้ปกติมีดังนี้
คำขอของผู้ใช้เพื่อแก้ไขข้อมูล (1) -> เว็บไซต์แสดงแบบฟอร์มข้อมูลที่แก้ไขของผู้ใช้ (2) -> ผู้ใช้แก้ไขข้อมูลและส่ง (3) -> เว็บไซต์ยอมรับข้อมูลและบันทึกที่แก้ไขของผู้ใช้ (4)
การโจมตี CSRF จะไม่ใช้เส้นทางนี้ แต่จะสร้างข้อมูลการส่งผู้ใช้โดยตรงในขั้นตอนที่ 2
ข้ามโดยตรงไปยังขั้นตอนที่ 2 (1) -> ปลอมแปลงข้อมูลที่จะแก้ไขและส่ง (2) -> เว็บไซต์ยอมรับผู้โจมตีเพื่อแก้ไขข้อมูลพารามิเตอร์และบันทึก (3)
ตราบใดที่สถานการณ์ทั้งสองนี้สามารถแยกแยะได้การโจมตี CSRF สามารถป้องกันได้ แล้วจะแยกแยะได้อย่างไร? เป็นการตรวจสอบข้อมูลที่ส่งในขั้นตอนที่ 2 เพื่อให้แน่ใจว่าข้อมูลมาจากแบบฟอร์มในขั้นตอนที่ 1 กระบวนการตรวจสอบเฉพาะมีดังนี้:
คำขอของผู้ใช้เพื่อแก้ไขข้อมูล (1) -> เว็บไซต์แสดงแบบฟอร์มเปล่าที่ใช้ในการแก้ไขข้อมูล แบบฟอร์มมีโทเค็นพิเศษและบันทึกโทเค็นในเซสชัน (2) -> ผู้ใช้แก้ไขข้อมูลและส่งและส่งข้อมูลโทเค็นกลับไปยังเซิร์ฟเวอร์ (3) -> เว็บไซต์เปรียบเทียบโทเค็นที่ส่งกลับโดยผู้ใช้และโทเค็นในเซสชัน มันควรจะสอดคล้องกัน จากนั้นข้อมูลที่แก้ไขโดยผู้ใช้จะได้รับการยอมรับและบันทึก
ด้วยวิธีนี้หากผู้โจมตีปลอมแปลงข้อมูลที่จะแก้ไขและส่งเขาจะไม่สามารถเข้าถึงเซสชันได้โดยตรงดังนั้นเขาจะไม่สามารถรับค่าโทเค็นที่แท้จริงได้ หากคำขอถูกส่งไปยังเซิร์ฟเวอร์เมื่อเซิร์ฟเวอร์ทำการตรวจสอบโทเค็นจะพบว่ามันไม่สอดคล้องกันและคำขอถูกปฏิเสธโดยตรง
โซลูชั่นกึ่งกลาง
ปิดการใช้งานแบบฟอร์มการส่ง
หากเซิร์ฟเวอร์ไม่ยอมรับข้อมูลแบบฟอร์มที่ส่งโดย GET มันจะทำให้เกิดปัญหาอย่างมากต่อผู้โจมตี เนื่องจากเป็นเรื่องง่ายมากที่จะสร้างแอตทริบิวต์ A-Label HREF หรือแอตทริบิวต์ IMG-label SRC บนหน้าเพื่อสร้างคำขอ แต่ถ้าคุณต้องการส่งคุณต้องใช้สคริปต์เพื่อนำไปใช้
ตรวจสอบคำขอด้วยโทเค็น CSRF
เนื่องจาก Midway ไม่เกี่ยวข้องกับตรรกะของเซสชันการกระจายของ Taobao และการตรวจสอบโทเค็นในกรอบ Midway เฉพาะโทเค็นเท่านั้นที่ถูกส่งต่อระหว่างเซิร์ฟเวอร์และลูกค้าและไม่ทำงานตรวจสอบจริง กระบวนการมีดังนี้:
ต่อจากนั้น: ในมิดเวย์หลังจากเซสชันการกระจายของ node.js และ taobao เชื่อมต่อคุณสามารถพิจารณาทำการตรวจสอบโทเค็นโดยอัตโนมัติที่เลเยอร์กึ่งกลาง; ท้ายที่สุดการตรวจสอบความปลอดภัยก่อนหน้านี้จะดำเนินการมากเท่าไหร่ค่าใช้จ่ายก็จะลดลง
ข้อเสนอแนะ: ในมิดเวย์คุณสามารถพิจารณาได้ว่ามีค่าโทเค็นในคำขอหรือไม่ หากการดำเนินการดัดแปลงไม่มีโทเค็นคุณสามารถพิจารณาได้โดยตรงในชั้นกึ่งกลางเพื่อไม่ปลอดภัยและยกเลิกคำขอ
ปัญหาด้านความปลอดภัยอื่น ๆ
มีปัญหาด้านความปลอดภัยเว็บทั่วไปหลายประการ ต่อไปนี้เป็นเพียงการแนะนำบางอย่างและจะยังคงได้รับการสืบทอดเข้าสู่กรอบการทำงานของมิดเวย์ในอนาคต
ความปลอดภัยส่วนหัว http
ผู้โจมตีการฉีด CRLF ค้นหาวิธีในการฉีดอักขระพิเศษ CRLF สองตัวลงในส่วนหัวการตอบสนองทำให้เกิดรูปแบบข้อมูลการตอบสนองที่ยอดเยี่ยมดังนั้นจึงฉีดสคริปต์ ฯลฯ
ถูกปฏิเสธการโจมตีการเข้าถึงทุกคำขอเนื่องจากคุกกี้ถูกนำมาโดยค่าเริ่มต้นและโดยทั่วไปแล้วเซิร์ฟเวอร์จะ จำกัด ขนาดของคุกกี้ซึ่งนำไปสู่ว่าหากคุกกี้ไคลเอนต์ผู้ใช้ถูกตั้งค่าให้เกินเกณฑ์ที่แน่นอนผู้ใช้จะไม่สามารถเข้าถึงเว็บไซต์ได้อีกต่อไป
การป้องกันและควบคุมคุกกี้การขโมยคุกกี้ทั่วไปผ่าน JavaScript (ช่องโหว่ XSS) ดังนั้นลองตั้งค่าคุกกี้เป็น HTTP เท่านั้นและเพิ่มเวลาหมดอายุคุกกี้
เกี่ยวกับปัญหาด้านความปลอดภัยของคุกกี้ WebX เคยมีทางออกที่ดีมาก่อน เวลานี้มิดเวย์จะไม่รับผิดชอบต่อการตั้งค่าและการตรวจสอบคุกกี้และรับผิดชอบเฉพาะการส่งต่อไปยังระดับเว็บ X สำหรับการตรวจสอบ
เกี่ยวกับ node.js
ช่องโหว่แบบฉีดเช่น XSS เป็นวิธีที่ง่ายที่สุดที่จะถูกเพิกเฉยในช่องโหว่ทั้งหมดคิดเป็นมากกว่า 70% ของการโจมตีทางอินเทอร์เน็ตทั้งหมด เมื่อเขียนรหัส Node.js นักพัฒนาควรเตือนตัวเองและไม่น่าเชื่อถืออินพุตของผู้ใช้
ตัวอย่างเช่นตัวอย่างต่อไปนี้
var mod = fs.readfilesync ('path'); หากพา ธ มาจากการป้อนข้อมูลของผู้ใช้สมมติว่าผู้ใช้ป้อน /etc /รหัสผ่านเนื้อหาที่ไม่ควรอ่านจะถูกอ่านทำให้เกิดความเสี่ยงของการรั่วไหลของรหัสผ่าน
var result = eval (jsonval); ตรวจสอบให้แน่ใจว่า JSONVAL เป็น JSON ไม่ใช่อินพุตของผู้ใช้
... ในสถานที่อื่น ๆ ที่อาจมีอินพุตผู้ใช้ให้แน่ใจว่าได้ยืนยันว่าการป้อนข้อมูลของผู้ใช้คือค่าที่เราคาดหวัง
สรุป
ในโหมดการแยกของส่วนหน้าและแบ็คเอนด์นักพัฒนาหน้าแบบดั้งเดิมสามารถเริ่มเขียนรหัสแบ็คเอนด์ได้ แม้ว่าสถาปัตยกรรมจะรับผิดชอบเฉพาะเลเยอร์เทมเพลต แต่ก็จะได้สัมผัสกับรหัสแบ็คเอนด์จำนวนมาก ดังนั้นการรักษาความปลอดภัยจึงเป็นความท้าทายที่ยิ่งใหญ่สำหรับส่วนหน้า