OWASP Top 10:2025 — tổng quan, phương pháp xếp hạng và bảng đối chiếu 2021 → 2025

Series OWASP Top 10:2025: Bài 0 — tổng quan (bài này) · Tiếp: Bài 1 — A01 Broken Access Control →

Câu mở màn quen thuộc của vòng phỏng vấn bảo mật cho Senior Backend / Tech Lead là "Anh kể tên OWASP Top 10 xem". Kể đủ mười cái tên thì ai cũng học thuộc được; thứ interviewer thật sự nghe là câu tiếp theo: danh sách này được làm ra thế nào, nó không phải là cái gì, bản 2025 đổi gì so với 2021 và vì sao, và trong team của anh nó được dùng ở bước nào của quy trình. Bài 0 là bản đồ của cả series: đọc xong bài này thì mỗi bài A01–A10 phía sau chỉ còn là đi sâu vào một ô trên bản đồ.

Vì sao bài này không theo khung 9 câu hỏi của CLAUDE.md, và vì sao không có lab. Bài về một danh sách rủi ro, không phải một công nghệ, nên dùng khung riêng của series (đã thống nhất trước). Đây là bài tổng quan: nó không khẳng định một kiểu tấn công nào "chạy được" hay một cách vá nào "chặn được". Các bài A01–A10 của series cũng không có lab (quyết định của series): chúng dựa trên tài liệu chính thức (OWASP, docs Laravel/NestJS) và ghi "chưa verify" ở chỗ cần lab mới khẳng định được. Mọi con số OWASP ở đây chép từ các trang chính thức top10.owasp.org/2025/en/ (Introduction, What are Application Security Risks, Establishing a Modern AppSec Program, Next Steps, và 10 trang A01–A10), đọc ngày 27/10/2026. Phép tính lại Risk Score ở mục 2.4 là số học trên bảng OWASP công bố (Python 3.14), không phải lab. Chỗ nào nguồn tự mâu thuẫn hoặc chỉ có nguồn thứ cấp thì ghi ở mục "Chưa verify".

1. OWASP Top 10 là gì — và không phải là gì

1.1 Là một awareness document, không phải một standard

1. Trang chủ bản 2025 tự định nghĩa: "The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications." Từ khoá là awareness document (tài liệu nâng cao nhận thức): mục tiêu là để một developer chưa từng học bảo mật biết mười nhóm rủi ro phổ biến và nguy hiểm nhất tồn tại, chứ không phải để làm danh sách kiểm tra "đạt/không đạt". Bản 2025 là "the 8th installment" (bản thứ 8) theo trang Introduction; trang về chương trình AppSec nói danh sách tồn tại "since its inception in 2003".

2. Chính OWASP nói thẳng ở trang "Establishing a Modern Application Security Program": "The OWASP Top 10 is primarily an awareness document. However, this has not stopped organizations from using it as a de facto industry AppSec standard since its inception in 2003. If you want to use the OWASP Top 10 as a coding or testing standard, know that it is the bare minimum and just a starting point." Tức là: dùng nó làm chuẩn thì được, nhưng phải hiểu đó là mức sàn (bare minimum), không phải mức đủ.

3. Lý do kỹ thuật khiến nó không làm standard tốt được: Top 10 mô tả rủi ro, không mô tả yêu cầu kiểm chứng được. OWASP lấy ví dụ: A06:2025 Insecure Design "is beyond the scope of most forms of testing"; còn việc logging/monitoring có thật sự hoạt động hay không "can only be done with interviews and requesting a sampling of effective incident responses". Một static analysis tool có thể thấy "thiếu dòng log", nhưng không thể biết business logic có log lại một vụ vượt quyền hay không. Kết luận của OWASP rất mạnh: "OWASP discourages any claims of full coverage of the OWASP Top 10, because it's simply untrue." — vendor nào quảng cáo "tool của chúng tôi phủ 100% OWASP Top 10" là đang nói điều OWASP bác bỏ.

4. Hệ quả thực tế: khi cần một standard (bộ yêu cầu có thể nghiệm thu), OWASP chỉ sang ASVS (Application Security Verification Standard — bộ yêu cầu kiểm chứng bảo mật ứng dụng), và nói rõ "The ASVS is the only acceptable choice for tool vendors." Bảng khuyến nghị của OWASP (chép nguyên):

1.2 Đặt cạnh các danh sách "họ hàng"

Interviewer hay hỏi nối: "Thế còn ASVS, CWE Top 25, API Top 10 thì khác gì?". Điểm mấu chốt để phân biệt là trả lời hai câu: đơn vị của danh sách là gì (nhóm rủi ro, yêu cầu, hay một điểm yếu cụ thể) và phạm vi là hệ thống loại nào (web app, API, mobile, ứng dụng LLM).

5. Vì sao OWASP không làm "Top 10 CWE" cho gọn như MITRE? Trang Introduction trả lời hai lý do: (a) không phải CWE nào cũng tồn tại trong mọi ngôn ngữ/framework, nên một danh sách 10 CWE sẽ có phần "không áp dụng" với nhiều team; (b) cùng một lỗ hổng phổ biến có nhiều CWE khác nhau (Injection, Command Injection, XSS, hardcoded password…), và mỗi tổ chức/tester gán CWE một kiểu — gom vào category giúp "raise the baseline and awareness of the different types of weaknesses that may occur under a common category name". Đổi lại, category rộng thì mơ hồ hơn khi dùng để đo: "app có lỗi A06" không cho biết sửa cái gì.

1.3 Trade-off: dùng như checklist hay dùng như bản đồ nhận thức

6. Dùng như checklist (vd mục "đã kiểm tra OWASP Top 10" trong MR template). Được: rẻ, ai cũng hiểu, ép người review ít nhất nghĩ tới mười hướng. Mất: cảm giác an toàn giả — mười ô đều tick nhưng những thứ không nằm trong danh sách (race condition trong nghiệp vụ, rủi ro đặc thù domain) bị bỏ qua; và vì mỗi category gom hàng chục CWE, một dòng "A05 Injection: OK" không nói người review đã kiểm tra những gì. Kiểu dùng này hợp với team nhỏ chưa có chương trình AppSec, như bước đầu tiên.

7. Dùng như bản đồ nhận thức (awareness). Được: đúng mục đích OWASP đặt ra, dùng để đào tạo, để định hướng threat modeling, để chọn nơi đầu tư tool. Mất: không đo được, không nghiệm thu được. Muốn đo thì phải đi xuống ASVS (requirement cụ thể, có level) — đó là chỗ một Tech Lead nên đưa team tới khi sản phẩm có dữ liệu nhạy cảm hoặc có khách hàng đòi bằng chứng bảo mật.

8. Cách dung hoà hay gặp trong thực tế (tổng hợp từ khuyến nghị của OWASP, không phải "một đáp án chuẩn"): Top 10 làm ngôn ngữ chung và chương trình đào tạo; ASVS (thường là L1 hoặc một bản fork rút gọn của L2) làm requirement; tool trong CI phủ phần tự động hoá được; threat modeling và code review phủ phần không tool nào phủ (A06, logic của A01, hiệu lực của A09).

2. Phương pháp 2025: dữ liệu đến từ đâu, xếp hạng thế nào

2.1 Dữ liệu: đo "tỉ lệ ứng dụng có lỗi", không đo "số lỗi"

1. OWASP xin dữ liệu từ các công ty test bảo mật (SAST/DAST vendor, bug bounty, consultancy). Danh sách đóng góp gồm Accenture (Prague), Bugcrowd, Contrast Security, CryptoNet Labs, Intuitor SoftTech Services, Orca Security, Probely, Semgrep, Sonar, usd AG, Veracode, Wallarm và nhiều đơn vị ẩn danh — tổng cộng dữ liệu của "over 2.8 millions applications".

2. Câu hỏi gửi đi là: mỗi năm (từ 2021) test bao nhiêu ứng dụng, và bao nhiêu ứng dụng có ít nhất một instance của từng CWE. OWASP cố ý bỏ qua frequency (tần suất): "Whether an application has four instances of a CWE or 4,000 instances is not part of the calculation". Lý do: tester thủ công thường ghi một lỗ hổng một lần dù nó lặp lại khắp app, còn tool tự động ghi từng instance — nếu đếm instance thì dữ liệu của tool tự động sẽ đè bẹp dữ liệu thủ công.

3. Ví dụ minh hoạ (số giả định): vendor X test 1.000 app, trong đó 37 app có ít nhất một chỗ thiếu kiểm tra quyền (CWE-862), một app trong số đó có 4.000 endpoint thiếu kiểm tra. Incidence rate của CWE-862 tại vendor X năm đó là 37 / 1.000 = 3,7% — app có 4.000 chỗ vẫn chỉ tính là một.

4. Hai chỉ số đi kèm, định nghĩa theo trang "What are Application Security Risks?": Incidence Rate = phần trăm ứng dụng mắc CWE đó trong số ứng dụng tổ chức đó test trong năm; Coverage (độ phủ test) = phần trăm ứng dụng được test cho CWE đó trên tổng số ứng dụng của mọi tổ chức. Coverage càng cao thì incidence rate càng đáng tin, vì mẫu đại diện hơn. Đây là chỗ hay bị hiểu nhầm: incidence thấp có thể chỉ vì ít ai test được loại lỗi đó (A03, A09 là ví dụ điển hình).

5. Quy mô dữ liệu CWE tăng mạnh qua các bản: "We went from approximately 30 CWEs in 2017, to almost 400 CWEs in 2021, to 589 CWEs in this edition". Sau khi gom, 10 category của 2025 chứa 248 CWE (theo Introduction), trung bình 25 CWE/category, thấp nhất 5 (A03, A09), cao nhất 40 (A01), và OWASP tự đặt trần 40 CWE/category. Từ điển CWE của MITRE lúc phát hành có 968 CWE.

2.2 Nửa còn lại của phương trình rủi ro: Exploit và Impact từ CVE

6. Tần suất chỉ là một nửa rủi ro. Nửa kia — khai thác dễ không, hậu quả lớn không — OWASP lấy từ CVE: tải OWASP Dependency Check, trích điểm CVSS Exploit và Impact, nhóm theo CWE gắn với CVE. Số liệu 2025: khoảng 175k bản ghi CVE → CWE trong NVD (2021 là 125k), 643 CWE duy nhất có gắn CVE (2021 là 241); trong gần 220k CVE trích ra có 160k điểm CVSS v2, 156k điểm v3 và 6k điểm v4 (một CVE có thể có nhiều điểm nên tổng vượt 220k).

7. Điểm được trộn theo tỉ trọng: nhóm CVE theo CWE, trung bình điểm Exploit và Impact có trọng số theo tỉ lệ CVE có CVSSv3 và phần còn lại chỉ có CVSSv2. Vì sao không dùng CVSS v4.0? Vì thuật toán v4 "no longer easily provides the Exploit or Impact scores as CVSS v2 and CVSSv3 do" — OWASP chưa tìm được cách quy đổi kịp cho bản 2025.

2.3 Công thức Risk Score

8. Trang "What are Application Security Risks?" công bố công thức (giống 2021, đổi trọng số):

Risk Score = (Max Incidence Rate % × 1000)
           + (Max Coverage % × 100)
           + (Avg Exploit × 10)
           + (Avg Impact × 20)
           + (Sum Occurrences / 10000)

Cách nói khi phỏng vấn: "Điểm rủi ro của mỗi nhóm là tổng năm phần. Phần nặng nhất là tỉ lệ ứng dụng mắc lỗi ở mức cao nhất trong nhóm — cứ thêm một phần trăm ứng dụng mắc lỗi là cộng mười điểm. Sau đó là độ phủ test, độ dễ khai thác và mức tác động lấy từ điểm CVSS của các CVE liên quan, trong đó tác động được nhân đôi trọng số so với khai thác. Cuối cùng cộng thêm một chút theo tổng số ứng dụng mắc lỗi, cứ mười nghìn ứng dụng là một điểm. Nên nhóm nào vừa phổ biến vừa được test rộng sẽ lên đầu, còn nhóm khó test thì gần như không thể leo lên bằng dữ liệu."

9. Trọng số nói lên điều gì? Max Incidence là một phần (vd 0,2015 cho 20,15%) nhân 1000, nên 1 điểm phần trăm = 10 điểm. Max Coverage 100% chỉ cho tối đa 100 điểm. Exploit (thang 10) × 10 → tối đa 100; Impact × 20 → tối đa 200. Occurrences: 100.000 ứng dụng = 10 điểm. OWASP công bố dải điểm thực tế: "The calculated scores ranged from 621.60 for the category of Broken Access Control to 271.08 for Memory Management Errors."

2.4 Thử tính lại từ bảng công bố — và vì sao đừng nói "thứ hạng do công thức quyết định"

10. Mỗi trang A01–A10 và trang Next Steps có một "Score table" (CWEs Mapped, Max/Avg Incidence, Max/Avg Coverage, Avg Weighted Exploit/Impact, Total Occurrences, Total CVEs). Ghép các cột đó vào công thức trên bằng Python để xem thứ hạng có tái tạo được không:

# risk_score.py — số liệu chép từ Score table của từng trang top10.owasp.org/2025/en/A0x_… và X01_2025-Next_Steps
rows = {  # max_incidence, max_coverage, avg_exploit, avg_impact, total_occurrences
    "A01 Broken Access Control":        (0.2015, 1.0000, 7.04, 3.84, 1_839_701),
    "A02 Security Misconfiguration":    (0.2770, 1.0000, 7.96, 3.97,   719_084),
    "A03 Software Supply Chain":        (0.0956, 0.6542, 8.17, 5.23,   215_248),
    "A04 Cryptographic Failures":       (0.1377, 1.0000, 7.23, 3.90, 1_665_348),
    "A05 Injection":                    (0.1377, 1.0000, 7.15, 4.32, 1_404_249),
    "A06 Insecure Design":              (0.2218, 0.8876, 6.96, 4.05,   729_882),
    "A07 Authentication Failures":      (0.1580, 1.0000, 7.69, 4.44, 1_120_673),
    "A08 Software/Data Integrity":      (0.0898, 0.7852, 7.11, 4.79,   501_327),
    "A09 Logging & Alerting":           (0.1133, 0.8596, 7.19, 2.65,   260_288),
    "A10 Exceptional Conditions":       (0.2067, 1.0000, 7.11, 3.81,   769_581),
    "X01 Lack of App Resilience":       (0.2005, 0.8601, 7.92, 3.49,   865_066),
    "X02 Memory Management Failures":   (0.0296, 0.5562, 6.75, 4.82,   220_414),
}
def score(mi, mc, ex, im, occ):
    return mi * 1000 + mc * 100 + ex * 10 + im * 20 + occ / 10000
for name, r in sorted(rows.items(), key=lambda kv: -score(*kv[1])):
    print(f"{name:32s} {score(*r):7.2f}")

$ python3 risk_score.py        # Python 3.14.7
A01 Broken Access Control         632.67
A02 Security Misconfiguration     607.91
A04 Cryptographic Failures        554.53
A05 Injection                     536.02
A07 Authentication Failures       535.77
A06 Insecure Design               534.15
A10 Exceptional Conditions        530.96
X01 Lack of App Resilience        522.02
A08 Software/Data Integrity       385.35
A03 Software Supply Chain         368.84
A09 Logging & Alerting            350.19
X02 Memory Management Failures    271.16

Cách nói khi phỏng vấn: "Tôi từng thử lấy đúng bảng điểm OWASP công bố cho từng nhóm rồi cộng lại theo công thức của họ. Kết quả gần đúng nhưng không khớp hẳn: Broken Access Control ra khoảng sáu trăm ba mươi hai điểm trong khi OWASP ghi sáu trăm hai mươi mốt, và thứ tự ở giữa bảng hơi lệch, ví dụ Software or Data Integrity Failures tính ra thấp hơn một nhóm đã bị loại. Điều đó cho thấy thứ hạng là 'dựa trên dữ liệu' chứ không 'do dữ liệu quyết định' — có bước gom nhóm và phán đoán của nhóm tác giả. Vì vậy tôi không dùng khoảng cách giữa hạng năm và hạng sáu để ưu tiên việc trong team; tôi dùng bối cảnh hệ thống của mình."

11. Đọc kết quả (đây là phép tính lại của bài này, không phải số OWASP công bố):

• A01 tính ra 632,67 = 201,5 (incidence) + 100 (coverage) + 70,4 (exploit) + 76,8 (impact) + 183,97 (occurrences), lệch ~11 điểm so với 621,60 OWASP ghi. X02 Memory Management ra 271,16 so với 271,08 — gần như khớp. Tức là công thức đúng là công thức họ dùng, nhưng đầu vào thật của họ (ở mức CWE, trước khi làm tròn và gom) không hoàn toàn trùng với bảng tóm tắt.
• A03 Software Supply Chain có Exploit/Impact cao nhất bảng (8,17 / 5,23) nhưng Max Incidence 9,56% và Coverage 65,42% kéo tổng xuống 368,84 — nếu chỉ dùng dữ liệu thì nó không vào top. Khớp với lời OWASP: "the fewest occurrences in the data, but also the highest average exploit and impact scores from CVEs", và nó vào danh sách nhờ survey.
• A09 Logging & Alerting thấp nhất trong mười (350,19), Impact chỉ 2,65 — đúng như OWASP viết: "This category will always be underrepresented in the data", và đây là lần thứ ba nó được survey đưa vào.
• Không tái tạo được thứ hạng ở giữa bảng: A07 (535,77) cao hơn A06 (534,15), và A08 (385,35) thấp hơn X01 Lack of Application Resilience (522,02) — nhóm đã bị đẩy xuống Next Steps. OWASP chỉ ghi ở X01 rằng "The scoring of this category was very close with A10:2025"; bài này không tìm được giải thích công khai vì sao A08 đứng trên X01 → ghi ở "Chưa verify".

2.5 Survey: vì sao dữ liệu thôi là chưa đủ

12. OWASP viết: "This installment of the Top Ten remains data-informed, but not blindly data-driven." Dữ liệu test là nhìn về quá khứ — từ lúc researcher tìm ra một loại lỗ hổng tới lúc tool test được nó ở quy mô lớn có thể mất nhiều năm, và có rủi ro có thể không bao giờ test tự động được. Nên một phần danh sách được dành cho community survey (khảo sát người làm AppSec và developer). Theo hình mapping chính thức, hai mục có dấu "From the Survey" năm 2025 là A03 Software Supply Chain Failures (đúng 50% người trả lời xếp nó hạng 1) và A09 Security Logging & Alerting Failures.

13. Lưu ý nguồn tự mâu thuẫn trong cách diễn đạt: đoạn Methodology viết "We ranked 12 categories based on the data contributed, and allowed two to be promoted or highlighted by responses from the community survey", còn đoạn "Why we use a community survey" viết "we only pick eight of the ten categories from the data … The other two categories are from the Top 10 community survey". Hai câu tương thích nếu hiểu là: xếp hạng 12 nhóm từ dữ liệu, giữ 8 nhóm, 2 suất còn lại do survey — và 12 − 8 − 2 nhóm dữ liệu dư ra thì rơi xuống Next Steps (X01, X02). Đây là cách hiểu của bài này, OWASP không viết đúng câu đó.

2.6 Root cause thay vì symptom

14. OWASP phân biệt hai loại CWE: root cause (nguyên nhân gốc — "Cryptographic Failure", "Misconfiguration") và symptom (triệu chứng — "Sensitive Data Exposure", "Denial of Service"). Họ chọn gom theo root cause "whenever possible as it's more logical for providing identification and remediation guidance". Lý do thực dụng: biết triệu chứng "lộ dữ liệu nhạy cảm" không nói cho developer phải sửa gì; biết nguyên nhân "không mã hoá / dùng thuật toán yếu / lộ key" thì biết ngay. Các lần đổi tên trong lịch sử đều theo hướng này: 2017 "Sensitive Data Exposure" → 2021 "Cryptographic Failures"; 2021 next step "Denial of Service" → 2025 X01 "Lack of Application Resilience" ("renamed as it described a symptom rather than a root cause").

15. Cái giá của root cause: các category chồng lên nhau. OWASP thừa nhận "it's basically impossible to create ten categories without some level of overlap". Ví dụ: thông báo lỗi lộ stack trace vừa có trong mô tả A02 Security Misconfiguration ("Error handling reveals stack traces…") vừa là CWE-209 của A10. Trong phỏng vấn, nói được "nó chồng lấn, và tôi xếp theo nguyên nhân: do cấu hình bật debug thì là A02, do code bắt exception sai thì là A10" là một câu trả lời tốt.

flowchart TD
  D["Dữ liệu đóng góp > 2,8 triệu ứng dụng<br/>số app được test + số app có ít nhất 1 CWE"] --> I["Incidence rate và Coverage<br/>theo từng CWE (589 CWE)"]
  N["NVD qua OWASP Dependency Check<br/>~175k bản ghi CVE → CWE"] --> E["Avg Exploit, Avg Impact<br/>CVSS v2/v3 có trọng số"]
  G["Gom CWE thành category<br/>ưu tiên root cause, trần 40 CWE"] --> S
  I --> S["Risk Score theo công thức"]
  E --> S
  S --> R["Xếp hạng 12 category từ dữ liệu"]
  R --> K["8 category giữ lại từ dữ liệu"]
  R --> X["Next Steps: X01 Resilience, X02 Memory"]
  V["Community survey"] --> P["2 suất: A03 Supply Chain, A09 Logging and Alerting"]
  K --> L["OWASP Top 10:2025"]
  P --> L

3. Mười mục của 2025 — mỗi mục một câu

Số liệu trong bảng lấy từ "Score table" trên trang chính thức của từng mục. "Avg incidence" là tỉ lệ trung bình ứng dụng mắc ít nhất một CWE của nhóm. Cột cuối là bài đi sâu trong series.

Ba con số đáng nhớ để nói khi phỏng vấn: A01 và A02 đều có "100% of the applications tested were found to have some form of" lỗi thuộc nhóm (tức là ứng dụng nào được test cũng có ít nhất một dạng); A05 Injection có nhiều CVE nhất (62.445, trong đó XSS hơn 30k và SQL Injection hơn 14k theo trang A05); A03 chỉ có 11 CVE nhưng avg incidence cao nhất bảng — dấu hiệu của một loại rủi ro khó test, không phải hiếm gặp.

4. Bảng đối chiếu 2021 → 2025

4.1 OWASP nói gì về thay đổi

1. Trang Introduction tóm tắt: "There are two new categories and one consolidation in the Top Ten for 2025." Hai mục mới là A03 Software Supply Chain Failures (mở rộng từ A06:2021) và A10 Mishandling of Exceptional Conditions; một lần hợp nhất là SSRF gộp vào A01. Mọi dòng dưới đây đã đối chiếu với trang Introduction, trang của từng mục và hình mapping chính thức (2025-mappings.png).

2. Có gì bị bỏ hẳn không? Không có mục 2021 nào biến mất hoàn toàn: SSRF vẫn còn, chỉ là một CWE trong A01. Những thứ "đứng ngoài" nằm ở trang Next Steps — so sánh hai bản:

flowchart LR
  subgraph y21["2021"]
    o01["A01 Broken Access Control"]
    o02["A02 Cryptographic Failures"]
    o03["A03 Injection"]
    o04["A04 Insecure Design"]
    o05["A05 Security Misconfiguration"]
    o06["A06 Vulnerable and Outdated Components"]
    o07["A07 Identification and Authentication Failures"]
    o08["A08 Software and Data Integrity Failures"]
    o09["A09 Logging and Monitoring Failures"]
    o10["A10 SSRF"]
  end
  subgraph y25["2025"]
    n01["A01 Broken Access Control"]
    n02["A02 Security Misconfiguration"]
    n03["A03 Software Supply Chain Failures (mới, survey)"]
    n04["A04 Cryptographic Failures"]
    n05["A05 Injection"]
    n06["A06 Insecure Design"]
    n07["A07 Authentication Failures"]
    n08["A08 Software or Data Integrity Failures"]
    n09["A09 Logging and Alerting Failures (survey)"]
    n10["A10 Mishandling of Exceptional Conditions (mới)"]
  end
  o01 -->|"giữ hạng 1"| n01
  o10 -.->|"gộp vào, CWE-918"| n01
  o05 -->|"lên 3 bậc"| n02
  o06 -->|"mở rộng phạm vi"| n03
  o02 -->|"tụt 2"| n04
  o03 -->|"tụt 2"| n05
  o04 -->|"tụt 2"| n06
  o07 -->|"đổi tên"| n07
  o08 -->|"and thành or"| n08
  o09 -->|"Monitoring thành Alerting"| n09

Cách nói khi phỏng vấn: "So với 2021 thì 2025 có hai mục mới và một lần gộp. Broken Access Control vẫn đứng đầu và nuốt luôn SSRF. Security Misconfiguration nhảy từ năm lên hai, và mục 'thư viện lỗi thời' của 2021 được mở rộng thành Software Supply Chain Failures ở hạng ba — tức là không chỉ thư viện có CVE mà cả build system, kênh phân phối, package bị cài mã độc. Ba mục mã hoá, injection và insecure design mỗi mục tụt hai bậc vì bị hai mục kia vượt. Bảy, tám, chín giữ hạng nhưng đổi tên, đáng nhớ nhất là logging thì nay nhấn vào alerting. Và mục mới ở hạng mười là xử lý tình huống bất thường, đặc biệt là lỗi thì cho qua."

4.2 Nếu interviewer học bản 2017: 2017 → 2021 trong một bảng

3. Nhiều interviewer học OWASP từ bản 2017 và vẫn nói "XSS là A7", "XXE là A4". Trang Introduction 2021 ghi: "three new categories, four categories with naming and scoping changes, and some consolidation". Ghép lại để nói được cả chuỗi 2017 → 2021 → 2025:

4. Mạch chung qua ba bản: access control leo từ hạng 5 (2017) lên hạng 1 và giữ; injection đi từ hạng 1 xuống 3 rồi 5; các mục symptom-based (Sensitive Data Exposure, XSS, XXE như một mục riêng) dần bị thay bằng hoặc gộp vào mục root-cause; và các mục khó test (components, logging, SSRF) thường vào danh sách nhờ survey chứ không nhờ dữ liệu.

5. Tech lead dùng danh sách này trong team thế nào

Nguyên tắc của OWASP ở trang "Establishing a Modern Application Security Program": thêm "one or more security activities to each phase of the system development life cycle", và nếu đã có chương trình thì đo độ trưởng thành bằng OWASP SAMM hoặc DSOMM. Với một team 4–7 developer, cách thực dụng là gắn mỗi category vào bước của quy trình có khả năng bắt nó rẻ nhất:

flowchart TD
  RQ["Yêu cầu / spec<br/>chọn ASVS level"] --> TM["Threat modeling<br/>A06, A01, A10"]
  TM --> CR["Code + review checklist<br/>A01, A05, A07, A10"]
  CR --> CI["CI: SAST, SCA, secret scan<br/>A05, A03, A04, A02"]
  CI --> ST["Staging: DAST, cấu hình<br/>A02, A05, A07"]
  ST --> PR["Production: log + alert, patch<br/>A09, A03"]
  PR -. "sự cố, pentest, bug report" .-> TM

5.1 Threat modeling — nơi duy nhất bắt được A06

1. OWASP viết về A06: "we need to move beyond 'shift-left' in the coding space, to pre-code activities such as requirements writing and application design". Không SAST nào phát hiện được "luồng nộp bài không chặn nộp sau hạn khi đổi múi giờ" vì đó không phải lỗi code mà là control không tồn tại. Thứ bắt được là một buổi threat modeling (mô hình hoá mối đe doạ) theo OWASP Threat Modeling Cheat Sheet: vẽ data flow, đánh dấu trust boundary, hỏi "kẻ xấu làm gì ở mỗi mũi tên".

2. Trade-off: threat modeling tốn thời gian người giỏi nhất team và dễ thành thủ tục. Cách giữ nó có giá trị: chỉ làm cho tính năng chạm vào tiền, điểm, dữ liệu cá nhân, quyền, hoặc gọi ra ngoài (URL do người dùng nhập — SSRF nay là A01); giới hạn 30–60 phút (số minh hoạ), kết quả là vài security user story (OWASP gợi ý "Add security user stories alongside all of your other user stories") chứ không phải tài liệu dài. Không hợp: CRUD nội bộ ít rủi ro — ở đó checklist review là đủ.

5.2 Code review checklist — dùng Top 10 làm khung, không làm nội dung

3. Top 10 là "bare minimum" cho peer review checklist theo bảng của OWASP. Biến nó thành câu hỏi cụ thể cho stack của team mới có ích; mười dòng "đã kiểm tra A01…A10" thì vô dụng. Ví dụ checklist cho Laravel/NestJS (câu hỏi do bài này đề xuất; cách làm chi tiết ở từng bài):

4. Trade-off: checklist dài làm review chậm và bị tick cho có. Cách phổ biến là để checklist trong MR template nhưng chỉ bắt buộc với MR chạm vào vùng nhạy cảm (auth, phân quyền, upload, thanh toán/điểm) — Minato đã có MR template bắt buộc cho migration/cache/job tương thích ngược (theo CV), nên thêm một mục bảo mật cùng chỗ là tự nhiên hơn là dựng quy trình mới.

5.3 SAST / DAST / SCA trong CI — tool phủ được gì, không phủ được gì

5. Ba loại tool, giải nghĩa: SAST (Static Application Security Testing — phân tích mã nguồn không chạy app), DAST (Dynamic — tấn công thử vào app đang chạy từ bên ngoài), SCA (Software Composition Analysis — đối chiếu dependency với cơ sở dữ liệu lỗ hổng). OWASP khuyến nghị "static analysis, software composition analysis, secret, and Infrastructure-as-Code (IaC) scanners" và lịch quét định kỳ "dynamic, static, secrets, IaC, and software composition analysis".

6. Phần CI/CD cụ thể (stage, cache, build một lần dùng cho 3 môi trường) đã có ở bài GitLab CI/CD cho Laravel; cách dùng static analysis với baseline và composer audit như "tầng thứ ba" của stage quality ở bài pint + static analysis; promote bằng tag ở bài git workflow. Bài này không lặp lại — chỉ thêm một ý: build một lần, deploy nhiều lần (artifact bất biến) vốn là một control của A08/A03, vì môi trường production chạy đúng artifact đã được quét.

5.4 Chọn ASVS level

7. ASVS 5.0.0 (phát hành 30/05/2025) định nghĩa ba level. Theo chương "What is the ASVS": L1 là "the minimum requirements … around 20% of the ASVS requirements", chủ yếu lớp phòng thủ đầu tiên; L2 là mức "Most applications should be striving to achieve", đạt L2 nghĩa là làm khoảng 70% requirement (toàn bộ L1 + L2); L3 là ~30% còn lại, chủ yếu defense-in-depth và control khó làm. ASVS không áp level cho ai: "an early-stage startup that is only collecting limited sensitive data may decide to focus on Level 1 … but a bank may have difficulty justifying anything less than Level 3".

8. ASVS còn khuyến khích fork: "each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, WebSockets, SOAP, if unused)", bắt đầu từ L1 rồi nâng theo rủi ro, giữ nguyên số hiệu requirement để truy vết. Với một LMS có điểm thi, dữ liệu cá nhân sinh viên và nhiều trường dùng chung (multi-tenant), lựa chọn hợp lý thường là L1 cho toàn hệ thống + L2 cho các vùng auth, phân quyền, upload, xuất dữ liệu — đây là đề xuất của bài này, không phải quy định của ASVS. Đổi lại: L2 đầy đủ là hàng trăm requirement, một team 4 người không làm hết trong một quý; fork rút gọn thì phải có người chịu trách nhiệm giữ nó cập nhật.

Khi nào KHÔNG nên dùng Top 10 làm thước đo. Khi khách hàng/kiểm toán đòi bằng chứng (dùng ASVS, có level và requirement kiểm chứng được); khi so sánh vendor tool (OWASP nói claim "phủ 100% Top 10" là sai); khi hệ thống chính là API thuần hoặc app LLM (dùng API Security Top 10, LLM Top 10 làm khung chính, Top 10 làm phụ); và khi ưu tiên backlog bảo mật — thứ hạng chung của ngành không thay được rủi ro cụ thể của hệ thống mình.

6. Thứ tự đọc series và cách trả lời "kể tên OWASP Top 10"

6.1 Đọc theo nhóm "control nằm ở đâu", không nhất thiết theo số

flowchart TD
  B0["Bài 0<br/>bản đồ"] --> G1["Nhóm 1: mỗi request<br/>A01, A05, A07"]
  G1 --> G2["Nhóm 2: nền tảng và build<br/>A02, A03, A08, A04"]
  G2 --> G3["Nhóm 3: thiết kế và vận hành<br/>A06, A10, A09"]

1. Nhóm 1 — control chạy trên mỗi request: A01 (có ai được làm việc này với object này không), A05 (input có bị diễn giải thành lệnh không), A07 (người này có thật là người này không). Đây là nhóm interviewer hỏi sâu nhất và là nơi code Laravel/NestJS hằng ngày hay sai nhất. Đọc trước. Phần RBAC/ABAC đã có sẵn ở bài RBAC và bài ABAC — Bài 1 sẽ link sang thay vì lặp.

2. Nhóm 2 — nền tảng, cấu hình, chuỗi build: A02, A03, A08, A04. Đọc A03 ngay trước A08 vì OWASP định nghĩa A08 là cùng vấn đề toàn vẹn nhưng "at a lower level". Bài nâng cấp PHP 8.4 vì PHP2Shell là một case thực tế của A03 (vá runtime có lỗ hổng).

3. Nhóm 3 — thiết kế và vận hành: A06, A10, A09. Đây là nhóm Tech Lead được kỳ vọng nói tốt hơn developer: thiết kế control, hành vi khi hỏng (fail open/closed), và phát hiện sự cố. Đọc cuối vì nó dựa trên ví dụ của hai nhóm trước.

4. Kế hoạch ôn gợi ý (minh hoạ, chỉnh theo lịch phỏng vấn): tuần 1 — Bài 0 + nhóm 1 (mỗi bài một buổi, tự trả lời mục "Câu hỏi phụ" không nhìn đáp án); tuần 2 — nhóm 2 + nhóm 3; ngày cuối — đọc lại mục 7 "Áp dụng vào CV" của cả 10 bài và tập nói to phần "Cách nói khi phỏng vấn".

6.2 Trả lời "kể tên OWASP Top 10"

Cách nói khi phỏng vấn: "Bản mới nhất là 2025. Đứng đầu vẫn là Broken Access Control, giờ gộp luôn SSRF. Thứ hai là Security Misconfiguration, thứ ba là Software Supply Chain Failures — bản mở rộng của mục thư viện lỗi thời. Rồi tới Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, và mục mới là Mishandling of Exceptional Conditions. Tôi hay nhớ theo ba nhóm: kiểm soát trên mỗi request là phân quyền, injection, xác thực; nền tảng và chuỗi build là cấu hình, supply chain, toàn vẹn, mã hoá; còn thiết kế và vận hành là insecure design, xử lý lỗi và logging-alerting. Và tôi coi nó là tài liệu nâng cao nhận thức, còn khi cần chuẩn để nghiệm thu thì dùng ASVS."

5. Bẫy thường gặp khi trả lời: (a) đọc danh sách 2021 và gọi là "mới nhất" — nhắc SSRF như mục số 10 là dấu hiệu lộ ngay; (b) nói "Top 10 là standard bảo mật" — OWASP tự nói là awareness; (c) kể tên mà không cho được một ví dụ trong hệ thống mình — interviewer sẽ hỏi "ở hệ thống của anh thì cái nào đáng lo nhất", và đó là mục 7.

7. Áp dụng vào hệ thống trong CV

Hai hệ thống trong cv-v3.md: LMS Uni (Moodle PHP + NestJS student portal + Next.js, MySQL primary/replica, Redis tách instance cho session/cache/lock, Nginx LB trước 3 app node, NFS cho moodledata, AWS S3, worker trên nhiều VPS, ~100.000 sinh viên, cao điểm ~8.000 đồng thời) và LMS Micro-learning (Laravel + Livewire modular monolith, NestJS, Next.js, PostgreSQL, Redis, MongoDB, MinIO, GitLab CI, Docker, 4 trường ~10.000 sinh viên). Bảng dưới chỉ là bản đồ; phân tích sâu nằm ở mục 7 của từng bài. Dấu * = giả định, CV không nói.

Câu trả lời nên chuẩn bị cho "Ở hệ thống của anh, mục nào đáng lo nhất?": A01 — vì student portal dùng chung database với Moodle nên toàn bộ logic phân quyền của Moodle phải được viết lại ở NestJS, và mọi API trả dữ liệu theo ID phải tự kiểm tra quyền sở hữu. Nói kèm cách đã/sẽ kiểm soát (guard/policy tập trung, test cho từng cặp user–object) — chi tiết ở Bài 1. Nếu thực tế portal đã giải quyết khác (vd gọi qua Moodle web service), Minato nên sửa câu này theo đúng hệ thống.

8. Câu hỏi phụ interviewer hay hỏi tiếp

Chưa verify

• Ngày phát hành bản 2025. Trang chính thức không ghi ngày. Nguồn thứ cấp (blog Fastly) ghi bản release candidate được công bố ngày 06/11/2025 tại OWASP Global AppSec; trang dự án owasp.org ghi 2025 là bản "most current released version". Bài này không khẳng định ngày bản final.
• Số liệu lệch nhau ngay trong nguồn OWASP (bài dùng số ở Score table của trang từng mục): A01 avg incidence 3,73% (Introduction) vs 3,74% (trang A01); A03 có 5 CWE (Introduction, Methodology) vs 6 (Score table và danh sách CWE trên trang A03), avg incidence 5,19% (đoạn Background) vs 5,72% (Score table); A05 có 38 CWE (Introduction) vs 37 (trang A05); tổng CWE của 10 mục 248 (Introduction) vs 249 (cộng Score table = số CWE riêng biệt bài này đếm được trong 10 danh sách).
• Phép tính lại Risk Score (mục 2.4) là của bài này: không tái tạo được 621,60 của A01 và không ra đúng thứ hạng giữa bảng (A07 > A06, A08 < X01). Không tìm được giải thích công khai; có thể do OWASP tính trên dữ liệu mức CWE chưa công bố.
• Cách hiểu "12 category xếp hạng / 8 từ dữ liệu / 2 từ survey" ở mục 2.5 là suy luận để dung hoà hai câu trong nguồn.
• Lý do SSRF gộp vào A01: OWASP chỉ ghi "has been rolled into this category"; giải thích bản chất ở mục 8 là quan điểm của bài này.
• Mục 7: mọi dòng có * là giả định về hệ thống, chưa đối chiếu với code/cấu hình thật.
• Khả năng phủ của từng loại tool ở mục 5.3 là tổng hợp chung, chưa chạy tool nào trong bài này; các bài A01–A10 cũng viết theo tài liệu, không có lab.

Nguồn

• OWASP Top 10:2025 — trang chủ: top10.owasp.org/2025/en/
• Introduction (thay đổi 2025, Methodology, cấu trúc category, survey, danh sách đóng góp dữ liệu): 0x00_2025-Introduction; hình mapping 2025-mappings.png
• What are Application Security Risks? (công thức Risk Score, định nghĩa data factors): 0x02_2025
• Establishing a Modern Application Security Program (bảng Top 10 vs ASVS, "Using the OWASP Top 10 as a standard"): 0x03_2025
• Next Steps 2025 (X01, X02, X03): X01_2025-Next_Steps; Next Steps 2021: A11_2021-Next_Steps
• Mười trang A01–A10:2025 (Background, Score table, danh sách CWE): A01 · A02 · A03 · A04 · A05 · A06 · A07 · A08 · A09 · A10
• OWASP Top 10:2021 Introduction (thay đổi 2017 → 2021): A00_2021_Introduction
• OWASP ASVS 5.0.0 — trang dự án: owasp.org/www-project-application-security-verification-standard; chương levels: 0x03-What-is-the-ASVS.md (tag v5.0.0)
• OWASP MASVS: mas.owasp.org/MASVS
• CWE Top 25 2025 (MITRE): 2025_cwe_top25
• OWASP API Security Top 10 – 2023: 0x11-t10
• OWASP Top 10 for LLM Applications 2025: genai.owasp.org/llm-top-10
• OWASP Threat Modeling Cheat Sheet: cheatsheetseries.owasp.org
• Nguồn thứ cấp về ngày công bố: Fastly blog
• Trong repo: GitLab CI/CD cho Laravel, pint + static analysis, git workflow, RBAC, ABAC, nâng cấp PHP 8.4 vì PHP2Shell, bảo mật agent; hệ thống trong CV: cv-v3.md

Series OWASP Top 10:2025: Bài 0 — tổng quan (bài này) · Tiếp: Bài 1 — A01 Broken Access Control →