Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là Technical PM của một sàn thương mại điện tử Việt Nam. Một sáng thứ Hai, team Growth báo cáo doanh số tăng vọt trong đêm — nghe có vẻ tốt, đúng không? Nhưng khi đào sâu, hóa ra hàng nghìn tài khoản bị chiếm đoạt, kẻ tấn công dùng điểm thưởng tích lũy của người dùng để mua hàng. Sự cố này không phải do "hacker thiên tài" nào cả, mà chỉ vì một lỗ hổng kinh điển nằm trong danh sách OWASP Top 10 — danh sách mà đáng lẽ team của bạn nên biết.
Là một Technical PM, bạn không cần viết code phòng thủ. Nhưng bạn là người ra quyết định về roadmap, ưu tiên, và đánh đổi (trade-off). Khi engineer nói "tính năng này cần thêm hai tuần để xử lý input validation", bạn cần hiểu họ đang nói về điều gì để không vô tình cắt phần đó đi vì áp lực deadline. Khi đội security gửi báo cáo pentest dày 30 trang, bạn cần biết lỗ hổng nào là "nhà đang cháy" và lỗ hổng nào có thể đưa vào backlog quý sau.
OWASP Top 10 là "ngôn ngữ chung" của ngành về bảo mật ứng dụng web. Hiểu nó giúp bạn giao tiếp với engineer, security team, và cả khách hàng doanh nghiệp (những người ngày càng hỏi về bảo mật trước khi ký hợp đồng). Bài này không biến bạn thành chuyên gia bảo mật — mục tiêu là cho bạn đủ "literacy" để đặt câu hỏi đúng, ưu tiên đúng, và không bị "lùa gà" bởi cả hai phía: engineer muốn làm quá kỹ, hoặc business muốn bỏ qua hoàn toàn.
Khái niệm cốt lõi
OWASP và Top 10 là gì
OWASP (Open Worldwide Application Security Project) là một tổ chức phi lợi nhuận, cộng đồng mở, chuyên về bảo mật phần mềm. Sản phẩm nổi tiếng nhất của họ là OWASP Top 10 — danh sách 10 nhóm rủi ro bảo mật phổ biến và nghiêm trọng nhất của ứng dụng web, được cập nhật vài năm một lần (các phiên bản gần đây: 2017, 2021, và bản 2025 đang được hoàn thiện) dựa trên dữ liệu thực tế từ hàng trăm nghìn ứng dụng.
Điểm quan trọng cần nắm: Top 10 không phải checklist đầy đủ để "tích xanh là an toàn". Nó là danh sách các nhóm rủi ro đáng quan tâm nhất — kiểu như "10 nguyên nhân tai nạn giao thông phổ biến nhất". Biết chúng giúp bạn tập trung nguồn lực vào nơi rủi ro cao nhất.
Mười nhóm rủi ro, giải thích cho PM
Dưới đây là phiên bản 2021 (vẫn là chuẩn được tham chiếu rộng rãi), diễn giải theo ngôn ngữ PM:
A01 — Broken Access Control (Kiểm soát truy cập bị hỏng): Đứng đầu bảng. Là khi người dùng làm được việc mà họ không được phép — ví dụ, đổi user_id=123 thành user_id=124 trên URL và xem được đơn hàng của người khác. Đây là lỗi PM dễ "ngửi" thấy nhất vì nó liên quan trực tiếp đến logic nghiệp vụ: "ai được xem gì, ai được làm gì".
A02 — Cryptographic Failures (Lỗi mã hóa): Dữ liệu nhạy cảm (mật khẩu, số thẻ, CMND/CCCD) bị lưu hoặc truyền mà không mã hóa đúng cách. Ví dụ: lưu mật khẩu dạng plaintext, hoặc website không bật HTTPS.
A03 — Injection: Kẻ tấn công "tiêm" lệnh độc hại qua ô nhập liệu. Kinh điển nhất là SQL Injection — gõ một đoạn mã vào ô tìm kiếm và khiến database trả về toàn bộ bảng người dùng.
A04 — Insecure Design (Thiết kế thiếu an toàn): Nhóm mới, rất "PM". Là khi bản thân thiết kế nghiệp vụ đã có lỗ hổng, không phải lỗi code. Ví dụ: cho phép đặt lại mật khẩu chỉ bằng câu hỏi bảo mật dễ đoán ("tên trường cấp 3 của bạn?"). Code chạy đúng, nhưng thiết kế sai.
A05 — Security Misconfiguration (Cấu hình sai): Để mặc định tài khoản admin/admin, mở cổng debug ra Internet, lộ thông báo lỗi chi tiết cho người dùng cuối.
A06 — Vulnerable and Outdated Components (Thành phần lỗi thời): Dùng thư viện, framework cũ có lỗ hổng đã được công bố. Đây là rủi ro lớn vì sản phẩm hiện đại dựa trên hàng trăm thư viện bên thứ ba.
A07 — Identification and Authentication Failures: Cơ chế đăng nhập yếu — cho phép mật khẩu "123456", không khóa tài khoản sau nhiều lần đăng nhập sai, để session không hết hạn.
A08 — Software and Data Integrity Failures: Tin tưởng dữ liệu/code từ nguồn không kiểm chứng, ví dụ tự động cập nhật từ một CDN bị xâm nhập.
A09 — Security Logging and Monitoring Failures: Không ghi log, không giám sát, nên khi bị tấn công thì không ai biết — đến khi quá muộn.
A10 — Server-Side Request Forgery (SSRF): Lừa server gọi đến một địa chỉ nội bộ mà kẻ tấn công không trực tiếp truy cập được, từ đó moi thông tin hạ tầng.
Vì sao PM cần phân biệt "design flaw" và "implementation bug"
Đây là góc nhìn quý giá nhất một PM mang lại. Nhiều mục trong Top 10 — đặc biệt A01 (Access Control) và A04 (Insecure Design) — bắt nguồn từ quyết định sản phẩm, không phải lỗi gõ nhầm của lập trình viên. Khi bạn viết acceptance criteria mà quên ghi rõ "chỉ chủ tài khoản mới xem được hóa đơn của mình", bạn vừa tạo tiền đề cho một lỗ hổng Broken Access Control. Bảo mật, vì thế, bắt đầu từ bàn của PM chứ không chỉ ở phòng engineer.
Tình huống thực tế
Tình huống 1: Sàn TMĐT và lỗ hổng IDOR (Broken Access Control)
Một startup TMĐT tại TP.HCM, tạm gọi là "ChợViệt", ra mắt tính năng tải hóa đơn điện tử. Endpoint là GET /api/invoices/{invoice_id}/pdf. Engineer làm rất nhanh, đúng deadline. Vấn đề: hệ thống chỉ kiểm tra người dùng đã đăng nhập hay chưa, nhưng không kiểm tra hóa đơn đó có thuộc về họ không.
Một người dùng tò mò đổi invoice_id từ 80451 thành 80452 và... thấy ngay hóa đơn của người khác, kèm tên, số điện thoại, địa chỉ. Đây gọi là lỗi IDOR (Insecure Direct Object Reference), một dạng phổ biến của A01. Vì ID chạy tuần tự, chỉ cần một script đơn giản là có thể tải về hàng chục nghìn hóa đơn — một vụ rò rỉ dữ liệu cá nhân quy mô lớn, đụng thẳng vào Nghị định 13/2023 về bảo vệ dữ liệu cá nhân.
Bài học rút ra: Lỗi này không nằm ở code phức tạp mà ở acceptance criteria thiếu sót. Nếu PM viết rõ "Hệ thống PHẢI từ chối (trả về 403) khi người dùng yêu cầu hóa đơn không thuộc về họ" và đưa case này vào kịch bản test, lỗ hổng đã không tồn tại. Quyền truy cập là việc của PM.
Tình huống 2: Ô tìm kiếm "thông minh" và SQL Injection (Injection)
Một công ty fintech cho vay tiêu dùng triển khai trang admin nội bộ để nhân viên CSKH tra cứu khách hàng theo tên. Vì là "công cụ nội bộ", team coi nhẹ và ghép thẳng chuỗi người dùng nhập vào câu lệnh SQL. Trong một đợt audit, chuyên gia bảo mật gõ vào ô tìm kiếm dòng ' OR '1'='1 và nhận về toàn bộ danh sách khách hàng. Tệ hơn, một biến thể của câu lệnh có thể xóa cả bảng dữ liệu.
Điều khiến vụ này nguy hiểm: niềm tin sai lầm rằng "công cụ nội bộ thì không cần bảo mật". Thực tế, một nhân viên bất mãn hoặc một máy tính nhân viên bị nhiễm mã độc là đủ để biến lỗ hổng nội bộ thành thảm họa.
Bài học rút ra: Injection gần như được "diệt sạch" nếu dùng parameterized queries (tham số hóa truy vấn) — một kỹ thuật chuẩn mà engineer đều biết. Vai trò của PM là không phân biệt đối xử về bảo mật giữa sản phẩm "đối ngoại" và "đối nội". Khi ước lượng công sức cho công cụ nội bộ, đừng để team mặc định cắt bỏ phần xử lý input an toàn.
Tình huống 3: Thư viện cũ và sự cố Log4Shell (Vulnerable Components)
Cuối năm 2021, cả thế giới công nghệ chao đảo vì lỗ hổng Log4Shell trong thư viện Log4j — một thư viện ghi log Java mà gần như mọi hệ thống Java đều dùng. Nhiều doanh nghiệp Việt Nam, từ ngân hàng đến ví điện tử, đã phải huy động đội ngũ làm việc xuyên đêm để rà soát và vá. Có công ty mất ba ngày chỉ để xác định họ có dùng Log4j ở đâu — vì không ai có danh sách đầy đủ các thư viện đang dùng.
Bài học rút ra: Đây là A06 — Vulnerable and Outdated Components. Là PM, bạn cần ủng hộ việc team duy trì một "SBOM" (Software Bill of Materials — danh mục thành phần phần mềm) và dành ngân sách định kỳ để cập nhật thư viện. Khoản đầu tư "vô hình" này khó bán cho stakeholder vì nó không tạo ra tính năng mới, nhưng nó quyết định bạn vá lỗ hổng trong 2 giờ hay 2 tuần khi sự cố nổ ra.
Hướng dẫn từng bước
Đây là quy trình thực dụng để một Technical PM đưa OWASP Top 10 vào công việc hằng ngày:
Bước 1 — Lập "bản đồ tài sản dữ liệu". Trước khi lo về lỗ hổng, hãy biết bạn đang bảo vệ cái gì. Liệt kê dữ liệu nhạy cảm trong sản phẩm: mật khẩu, thông tin thanh toán, CCCD, dữ liệu sức khỏe, vị trí. Dữ liệu càng nhạy cảm, rủi ro càng cần ưu tiên.
Bước 2 — Đưa "security thinking" vào giai đoạn thiết kế. Khi viết spec cho một tính năng, thêm một mục ngắn: "Ai được phép làm hành động này?" và "Điều gì xảy ra nếu người dùng cố làm điều họ không được phép?". Chỉ riêng hai câu hỏi này đã chặn phần lớn lỗi A01 và A04.
Bước 3 — Biến yêu cầu bảo mật thành acceptance criteria. Thay vì để bảo mật là "việc ngầm hiểu", hãy viết rõ. Ví dụ: "GIVEN người dùng A đã đăng nhập, WHEN họ yêu cầu xem đơn hàng của người dùng B, THEN hệ thống trả về lỗi 403 và ghi log sự kiện."
Bước 4 — Ưu tiên theo rủi ro, không theo cảm tính. Khi nhận báo cáo pentest hoặc bug bảo mật, dùng công thức đơn giản: Rủi ro = Khả năng xảy ra × Mức độ thiệt hại. Một lỗ hổng để lộ toàn bộ database (thiệt hại cao) mà ai cũng khai thác được (khả năng cao) phải được vá ngay; một lỗ hổng chỉ khai thác được khi đã có quyền admin có thể đưa vào backlog.
Bước 5 — Tích hợp kiểm tra tự động vào quy trình. Ủng hộ engineer đưa các công cụ quét bảo mật (SAST, dependency scanning như Dependabot, Snyk) vào pipeline CI/CD. Là PM, bạn không chạy công cụ, nhưng bạn bảo vệ thời gian để team thiết lập chúng.
Bước 6 — Lên kế hoạch cho "ngày tồi tệ". Phối hợp với team để có sẵn quy trình khi lỗ hổng được phát hiện: ai được thông báo, bao lâu phải vá, ai liên hệ khách hàng. (Phần này sẽ được đào sâu ở các bài về Incident Response.)
Lỗi thường gặp & mẹo
Lỗi 1 — Coi bảo mật là "việc của team security, không phải của PM". Như đã thấy, nhiều lỗ hổng bắt nguồn từ quyết định sản phẩm. PM đẩy hết trách nhiệm sang nơi khác là đang bỏ qua phần mình kiểm soát tốt nhất.
Lỗi 2 — "Security theater" — làm cho có. Bắt người dùng đổi mật khẩu mỗi 30 ngày, ép mật khẩu phức tạp đến mức họ phải ghi ra giấy dán màn hình. Những biện pháp này trông "an toàn" nhưng thực tế làm giảm bảo mật và phá trải nghiệm. Mẹo: ưu tiên giải pháp nền tảng (như xác thực hai lớp) thay vì các quy tắc gây phiền nhiễu.
Lỗi 3 — Bỏ qua công cụ nội bộ và môi trường staging. Như tình huống fintech ở trên, "nội bộ" không có nghĩa là "an toàn". Mẹo: áp dụng cùng tiêu chuẩn cho mọi nơi chạm vào dữ liệu thật.
Lỗi 4 — Để báo cáo pentest "đắp chiếu". Nhiều công ty thuê pentest để có chứng nhận rồi cất báo cáo vào ngăn kéo. Mẹo: với mỗi phát hiện, tạo một ticket trong backlog có người chịu trách nhiệm và hạn vá rõ ràng.
Mẹo vàng — Học cách đặt câu hỏi đúng. Bạn không cần biết cách vá SQL Injection, nhưng nên hỏi được: "Tính năng này có dùng parameterized query không?", "Endpoint này kiểm tra quyền sở hữu tài nguyên ở đâu?", "Lần cuối ta cập nhật các thư viện phụ thuộc là khi nào?". Những câu hỏi này khiến engineer thấy bạn là đối tác đáng tin về bảo mật, không phải người chỉ hối deadline.
Bài tập thực hành
Bài 1 — Đối chiếu sản phẩm của bạn: Lấy một tính năng trong sản phẩm bạn đang làm (hoặc một app bạn dùng hằng ngày). Với mỗi mục trong OWASP Top 10, viết một câu trả lời cho: "Tính năng này có thể dính rủi ro này không, và nếu có thì như thế nào?". Mục tiêu là rèn phản xạ "ngửi" rủi ro.
Bài 2 — Viết lại acceptance criteria: Lấy một user story bất kỳ có liên quan đến dữ liệu người dùng (ví dụ "Người dùng xem lịch sử giao dịch"). Bổ sung ít nhất hai acceptance criteria về kiểm soát truy cập và xử lý truy cập trái phép, theo định dạng GIVEN/WHEN/THEN.
Bài 3 — Ưu tiên rủi ro: Cho ba lỗ hổng giả định — (a) mật khẩu lưu plaintext trong database, (b) thông báo lỗi lộ phiên bản framework, (c) IDOR cho phép xem hóa đơn người khác. Dùng công thức Rủi ro = Khả năng × Thiệt hại để xếp hạng và viết một đoạn ngắn giải thích lựa chọn của bạn cho stakeholder không rành kỹ thuật.
Bài 4 — Soạn câu hỏi review: Viết một danh sách 5 câu hỏi bảo mật bạn sẽ hỏi trong buổi review thiết kế của một tính năng đăng nhập mới, dựa trên các nhóm rủi ro A01, A02, A07.
Tóm tắt
OWASP Top 10 là danh sách 10 nhóm rủi ro bảo mật web phổ biến và nghiêm trọng nhất, do tổ chức OWASP duy trì và cập nhật vài năm một lần. Là Technical PM, bạn không cần là chuyên gia vá lỗi, nhưng cần đủ hiểu biết để giao tiếp, ưu tiên và ra quyết định đúng.
Ba điều cốt lõi cần nhớ: Một, nhiều lỗ hổng — đặc biệt Broken Access Control (A01) và Insecure Design (A04) — bắt nguồn từ quyết định sản phẩm, nên bảo mật bắt đầu ngay từ bàn của PM, qua spec và acceptance criteria. Hai, hãy ưu tiên theo rủi ro thực (Khả năng × Thiệt hại), không theo cảm tính hay deadline. Ba, đừng phân biệt đối xử về bảo mật giữa sản phẩm đối ngoại và công cụ nội bộ — dữ liệu thật ở đâu thì tiêu chuẩn ở đó.
Qua ba tình huống — IDOR ở sàn TMĐT, SQL Injection ở công cụ nội bộ fintech, và cơn địa chấn Log4Shell — ta thấy điểm chung: lỗ hổng nghiêm trọng thường không đến từ kỹ thuật cao siêu, mà từ những thiếu sót cơ bản trong thiết kế và quy trình. Đó chính xác là nơi một PM giỏi có thể tạo khác biệt. Các bài tiếp theo về Authentication vs Authorization, Encryption, và Incident Response sẽ giúp bạn đào sâu từng mảnh ghép này.