Khi bạn đạt đến level Principal Frontend Engineer, bạn không chỉ code mà còn phải định hướng kiến trúc, giảm rủi ro hệ thống, và đảm bảo an toàn cho người dùng. Security không còn là việc của riêng Backend hay DevOps – nếu ứng dụng của bạn bị tấn công, bạn sẽ là người đầu tiên nhận trách nhiệm.
Dưới đây là cách tôi tiếp cận Frontend Security
1. Security Là Một Phần Của Kiến Trúc, Không Phải "Thêm Vào Sau"
🔐 Nguyên Tắc Thiết Kế
- "Secure By Default": Mọi thành phần mới phải tuân thủ security guidelines ngay từ đầu.
- "Least Privilege": Giới hạn quyền tối đa cần thiết (vd: API chỉ được truy cập từ domain cụ thể).
- "Defense In Depth": Nhiều lớp bảo vệ (CSP + CORS + Input Sanitization).
📌 Case Study: Lỗi XSS Trong Widget Third-Party
- Vấn đề: Một team sử dụng chat widget từ nhà cung cấp bên thứ ba, nhưng không kiểm tra kỹ, dẫn đến DOM-based XSS.
- Giải Pháp Của Principal FE:
- CSP nghiêm ngặt để chặn inline script.
- SRI (Subresource Integrity) để đảm bảo script không bị tampered.
- Isolate widget trong Shadow DOM để giảm attack surface.
<script src="https://third-party.com/widget.js" integrity="sha384-..." crossorigin="anonymous">
</script>
2. Không Chỉ Fix Vulnerabilities, Mà Phải Ngăn Chặn Từ Gốc
🛡️ Cách Tôi Triển Khai Security Trong Code Review
Loại Lỗi | Câu Hỏi Khi Review | Cách Phòng Ngừa |
---|---|---|
XSS | "Data này có được escape/sanitize trước khi render không?" | Bắt buộc dùng thư viện như DOMPurify. |
CSRF | "API này có CSRF token hoặc SameSite cookie không?" | Yêu cầu tích hợp CSRF middleware. |
CORS | "Có cần thiết để Access-Control-Allow-Origin: * không?" |
Chỉ cho phép domain cụ thể. |
🔍 Ví Dụ Thực Tế: Lỗ Hổng Trong Form Upload
- Phát Hiện: Một form upload cho phép file
.html
, có thể dẫn đến Stored XSS. - Cách Xử Lý:
// ❌ Nguy hiểm: Cho phép mọi file type accept="*" // ✅ Principal Engineer sẽ enforce: accept=".jpg,.png,.pdf" // Chỉ cho phép file an toàn
- Server-side validation (dù là Frontend, tôi vẫn yêu cầu Backend kiểm tra lại).
3. Không Chỉ Code – Mà Còn Là Quy Trình & Văn Hóa
📜 Security Checklist Trước Khi Release
Tôi đưa vào quy trình của team:
- Dependency Scanning (
npm audit
, Snyk). - Automated Security Testing (OWASP ZAP trong CI/CD).
- Manual Pentest cho critical features (nếu cần).
👥 Đào Tạo Team Về Security Awareness
- Workshop hàng quý về các lỗ hổng mới (ví dụ: Prototype Pollution).
- Capture The Flag (CTF) mini để team thực hành.
4. Khi Sự Cố Xảy Ra – Cách Một Principal FE Phản Ứng
🚨 Quy Trình Xử Lý Incident
- Ngay lập tức: Rollback nếu cần.
- Forensic Analysis: Xác định root cause (vd: Lỗi từ thư viện nào?).
- Hotfix: Patch nhanh + test nghiêm ngặt.
- Post-mortem: Viết báo cáo & cải tiến process.
💡 Bài Học Từ Một Real Incident
- Sự cố: Một thư viện npm bị compromised, inject malware vào production.
- Action của tôi:
- Tắt ngay CDN chứa thư viện độc hại.
- Chuyển sang locked dependencies (
package-lock.json
nghiêm ngặt). - Triển khai automated SBOM (Software Bill of Materials) để theo dõi dependencies.
Kết Luận: Tư Duy Security Của Một Principal Engineer
Là một Principal Frontend Engineer, tôi không chỉ giải quyết vấn đề – mà thiết kế hệ thống để ngăn chúng xảy ra. Cụ thể:
✅ Security là requirement ngang hàng với performance và UX.
✅ Mọi decision (từ chọn thư viện đến API design) đều cân nhắc risk.
✅ Không chỉ bảo vệ ứng dụng – mà còn đảm bảo an toàn cho người dùng.
Hãy comment để tôi biết bạn quan tâm chủ đề nào tiếp theo nhé! 🚀