Security Căn Bản

Level: L6 — AI Coding & Vibe Coding (Bài 10/12 theo thứ tự sản xuất — · Đối tượng: Người đã học bài 53-61, dự án tích lũy đã chạy đúng, đã có

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Giải thích vì sao secrets (API key, mật khẩu) không bao giờ được để lộ trong code, và phải làm gì nếu lỡ để lộ.
Nhận diện 4 rủi ro bảo mật phổ biến nhất với 1 sản phẩm cá nhân quy mô nhỏ, theo tiêu chuẩn ngành OWASP.
Dùng Claude Code để rà soát lỗ hổng phổ biến trước khi thêm tính năng gọi API bên ngoài (bài 64) và trước khi deploy (bài 63).
Chuẩn bị đúng cách lưu trữ API key cho tính năng AI tóm tắt sắp thêm.

2. Khái niệm cốt lõi

Secrets là gì, và vì sao không bao giờ được đặt trực tiếp trong code: “secrets” là các credential nhạy cảm cấp quyền truy cập hệ thống/dịch vụ — cụ thể: API key, mật khẩu, token [S100]. Khi 1 secret được ghi thẳng vào code và commit lên Git (đã học bài 54), nó “trở thành mục tiêu cho truy cập trái phép” [S100] — và tồn tại vĩnh viễn trong lịch sử Git trên mọi nhánh, rất khó gỡ bỏ hoàn toàn dù sau đó có xóa ở phiên bản mới nhất [S100]. Đây là lý do secrets phải được lưu tách biệt khỏi code ngay từ đầu, không phải “sửa sau.”

Nếu lỡ để lộ 1 secret — bước quan trọng nhất không phải cố xóa lịch sử Git: nguồn chính thức nhấn mạnh biện pháp khắc phục chính là xoay vòng (rotate) credential ngay lập tức — tạo key/mật khẩu mới, vô hiệu hóa cái cũ [S100]. Cố gắng xóa khỏi lịch sử Git tốn thời gian và thường không cần thiết nếu credential đã bị vô hiệu hóa [S100].

4 rủi ro bảo mật phổ biến nhất với 1 sản phẩm cá nhân quy mô nhỏ (chọn lọc từ OWASP Top 10:2025 — tiêu chuẩn ngành chính thức, 10 mục đầy đủ, ở đây chỉ dùng 4 mục liên quan trực tiếp tới quy mô dự án tích lũy, không dạy đủ 10 mục vì vượt phạm vi người mới bắt đầu) [S99]:

Cryptographic Failures (A04) — bao gồm để lộ secrets, đúng nội dung đã học ở trên.
Injection (A05) — tấn công khai thác do không kiểm tra dữ liệu đầu vào (input validation): ví dụ người dùng nhập nội dung ghi chú chứa mã độc thay vì văn bản thường, hệ thống xử lý mù quáng mà không kiểm tra.
Broken Access Control (A01) — lỗ hổng phân quyền: ví dụ người dùng A xem/xóa được ghi chú của người dùng B, do hệ thống không kiểm tra đúng ai đang thao tác với ghi chú nào.
Security Misconfiguration (A02) — cấu hình bảo mật sai hoặc dùng mặc định không an toàn (ví dụ: để chế độ “hiển thị lỗi chi tiết” bật công khai khi sản phẩm đã deploy, vô tình lộ thông tin nội bộ).

3. Tại sao nội dung này quan trọng

Bài 56 đã trích số liệu thật: code AI-đồng-tác-giả không qua review có lỗ hổng bảo mật cao hơn 2,74 lần so với code được viết/review cẩn thận [S97, dẫn lại]. Bài này là bước bù đắp trực tiếp cho đúng rủi ro đó, ngay trước khi dự án tích lũy thêm tính năng gọi API bên ngoài (bài 64, cần lưu trữ đúng cách 1 API key thật) và deploy công khai (bài 63).

4. Cơ chế hoạt động

Phân định AI vs con người (đúng nguyên tắc bất biến đã đặt ra ở kế hoạch Level 6 cho giai đoạn Secure):

	Điều bạn cần hiểu	Điều AI có thể thực hiện	Điều bạn phải xác nhận
Secrets	Secret không bao giờ nằm trong code, và tồn tại vĩnh viễn trong lịch sử Git nếu lỡ commit	Rà soát code tìm secret bị hardcode, đề xuất cách lưu tách biệt	Không có secret/dữ liệu nhạy cảm nào bị lộ — đây là xác nhận con người quan trọng nhất giai đoạn Secure
Input validation	Dữ liệu người dùng nhập vào không bao giờ nên được tin tuyệt đối	Đề xuất/thêm bước kiểm tra input	Các bước kiểm tra có phủ đúng những chỗ người dùng thực sự nhập dữ liệu
Access control	Ai được phép làm gì với dữ liệu của ai	Rà soát, chỉ ra chỗ thiếu kiểm tra quyền	Đã thử với góc nhìn “người dùng khác” xem có truy cập được dữ liệu không nên thấy
Cấu hình	Cấu hình mặc định thường ưu tiên tiện lợi hơn an toàn	Đề xuất cấu hình an toàn hơn cho môi trường thật	Cấu hình khi deploy (bài 63) khác cấu hình khi phát triển cục bộ

5. Mental model

Nếu bài 61 là lắp cảm biến rò nước, bài này là lúc bạn kiểm tra khóa cửa và cất chìa khóa dự phòng đúng chỗ trước khi mời người lạ (dịch vụ AI bên ngoài, bài 64) vào nhà và trước khi mở cửa cho công chúng (deploy, bài 63). Secrets giống như chìa khóa nhà — không bao giờ dán công khai ngay trước cửa (code commit lên Git), mà cất ở nơi riêng biệt chỉ người có quyền mới lấy được.

6. Hướng dẫn từng bước

Áp dụng cho dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.

Trước khi thêm tính năng AI tóm tắt (bài 64) — tính năng này cần 1 API key thật để gọi dịch vụ AI bên ngoài — chuẩn bị đúng cách ngay từ bây giờ:

Yêu cầu Claude Code rà soát secrets — ví dụ: “kiểm tra xem có credential/API key nào đang bị viết trực tiếp trong code không.”
Thiết lập cách lưu secrets tách biệt — yêu cầu Claude Code hướng dẫn cách lưu API key sắp dùng ở bài 64 theo cách chuẩn của dự án (tách khỏi code, không commit lên Git) — chuẩn bị trước khi thực sự cần key thật.
Rà soát input validation — yêu cầu: “kiểm tra chức năng thêm ghi chú có xác nhận đúng dữ liệu đầu vào không, ví dụ ghi chú rỗng hoặc quá dài.”
Rà soát access control — với ứng dụng nhiều người dùng (nếu dự án của bạn có), xác nhận 1 người dùng không xem/xóa được ghi chú của người khác.
Xác nhận cấu hình an toàn trước khi deploy — kiểm tra không có thông tin nội bộ (đường dẫn hệ thống, thông báo lỗi chi tiết) bị hiển thị công khai — chuẩn bị cho bài 63.

7. Ví dụ thực tế

Vì sao chuẩn bị lưu API key đúng cách trước khi có key thật quan trọng: nếu bạn thêm tính năng AI tóm tắt (bài 64) trước, rồi mới nghĩ tới bảo mật sau, rủi ro cao là API key đã bị viết thẳng vào code và có thể đã commit lên Git ít nhất 1 lần — đúng đúng rủi ro “tồn tại vĩnh viễn trong lịch sử” đã học ở mục 2. Học và thiết lập cách lưu đúng trước khi có key thật (thứ tự đúng của bài này, trước bài 64) tránh được rủi ro đó hoàn toàn, thay vì phải xoay vòng key sau khi đã lỡ để lộ.

8. Prompt/template/workflow

Khung rà soát bảo mật cơ bản tái sử dụng:

Rà soát code của dự án cho 4 rủi ro sau:
1. Có credential/API key nào bị viết trực tiếp trong code không?
2. Dữ liệu người dùng nhập vào có được kiểm tra trước khi xử lý không?
3. Người dùng có thể truy cập dữ liệu của người dùng khác không?
4. Có thông tin nội bộ nào bị hiển thị công khai khi có lỗi không?
Đề xuất cách khắc phục cho từng điểm phát hiện được.

Checklist trước khi thêm API key thật hoặc deploy:

[ ] Không có secret nào bị viết trực tiếp trong code?
[ ] Secrets được lưu tách biệt (không commit lên Git)?
[ ] Dữ liệu đầu vào quan trọng đã được kiểm tra?
[ ] Đã thử góc nhìn "người dùng khác" để kiểm tra phân quyền?

9. Visual hoặc diagram cần thiết

Hình 6.10 — Security: API key đúng cách (tách biệt, có khoá) vs sai cách (trong code).

10. Bài tập thực hành

Yêu cầu Claude Code rà soát dự án của bạn theo khung ở mục 8.
Nếu phát hiện bất kỳ secret nào bị hardcode (kể cả secret thử nghiệm), thực hành chuyển sang cách lưu tách biệt.
Thử nhập dữ liệu bất thường (ghi chú rỗng, ghi chú rất dài, ký tự đặc biệt) vào chức năng thêm ghi chú, quan sát hệ thống xử lý thế nào.
Chuẩn bị trước cách lưu API key cho tính năng AI tóm tắt (bài 64) — xác nhận với Claude Code đây là cách lưu tách biệt, không hardcode.

11. Checklist

Giải thích được vì sao secrets không bao giờ đặt trong code.
Biết bước quan trọng nhất nếu lỡ để lộ secret (xoay vòng, không chỉ xóa lịch sử Git).
Nhận diện được 4 rủi ro bảo mật phổ biến nhất theo OWASP.
Đã rà soát dự án tích lũy theo khung ở mục 8.
Không nhầm phạm vi bài này với bảo mật kết nối/dữ liệu (Level 7).

12. Lỗi thường gặp

Viết API key trực tiếp vào code “để test nhanh”, định xóa sau — rất dễ quên, và nếu đã commit dù chỉ 1 lần, secret đã tồn tại trong lịch sử Git.
Chỉ cố xóa secret khỏi phiên bản mới nhất khi phát hiện lộ, không xoay vòng credential — secret cũ vẫn còn hiệu lực và vẫn nằm trong lịch sử.
Tin tuyệt đối mọi dữ liệu người dùng nhập vào mà không kiểm tra — nguồn gốc phổ biến nhất của lỗ hổng Injection.
Chỉ nghĩ tới bảo mật sau khi deploy — nên rà soát trước, đúng thứ tự SECURE trước DEPLOY trong hành trình Level 6.

13. Giới hạn & khi nào KHÔNG nên áp dụng

Bài này không dạy bảo mật kết nối/dữ liệu khi AI truy cập công cụ ngoài (OAuth scope, MCP) — xem Level 7 (#74-75) khi có.
Bài này chỉ dạy 4/10 rủi ro OWASP liên quan trực tiếp nhất tới dự án cá nhân quy mô nhỏ — với sản phẩm thật sự nghiêm túc/nhiều người dùng, cần rà soát đầy đủ hơn, lý tưởng nhất có chuyên gia bảo mật xem lại.
Rà soát bằng AI ở bài này là bước sàng lọc cơ bản, không thay thế kiểm toán bảo mật chuyên nghiệp cho sản phẩm xử lý dữ liệu nhạy cảm thật (tài chính, y tế…).

14. An toàn & quản trị (Safety/Governance)

Đây là bài mà chính nội dung là an toàn/quản trị — không có mục riêng tách biệt cần bổ sung. Nguyên tắc quan trọng nhất xuyên suốt: secrets không bao giờ là quyết định của AI một mình — AI có thể rà soát và đề xuất, nhưng con người là người xác nhận cuối cùng không có secret nào bị lộ, đúng nguyên tắc bất biến đã đặt ra từ đầu Level 6 cho vai trò con người ở giai đoạn Secure.

15. Best practices

Thiết lập cách lưu secrets tách biệt trước khi có secret thật cần dùng, không phải sau khi đã lỡ hardcode.
Coi mọi dữ liệu người dùng nhập vào là “chưa đáng tin” cho tới khi được kiểm tra — nguyên tắc nền tảng của input validation.
Nếu phát hiện secret đã bị lộ, xoay vòng ngay lập tức — không trì hoãn để “xử lý sau.”

16. Nội dung nâng cao (không bắt buộc)

OWASP Top 10 đầy đủ còn 6 mục khác (Software Supply Chain Failures, Insecure Design, Authentication Failures, Software/Data Integrity Failures, Security Logging Failures, Mishandling of Exceptional Conditions) [S99] — quan trọng ở quy mô tổ chức/nhiều người dùng hơn nhiều so với phạm vi 1 dự án cá nhân mới bắt đầu của Level 6. Người học muốn đi sâu hơn về bảo mật phần mềm nên tham khảo trực tiếp tài liệu OWASP đầy đủ sau khi hoàn thành Level 6.

17. Nguồn tham khảo

[S99] OWASP Top 10:2025, OWASP — owasp.org/Top10/2025 — danh sách 10 rủi ro bảo mật ứng dụng web hàng đầu, tiêu chuẩn ngành chính thức.
[S100] About Secret Scanning, GitHub Docs — docs.github.com — định nghĩa secrets, rủi ro khi commit vào Git, biện pháp khắc phục chính (xoay vòng credential).
Dẫn chiếu (không trích dẫn mới): [S97] (số liệu rủi ro bảo mật khi AI đồng tác giả, đã trích đầy đủ ở bài 56); bài 54 (Git, lịch sử commit); bài 55 (mô hình 4 lớp, dùng để xác định API key thuộc lớp nào).

18. Ngày kiểm chứng

Danh sách OWASP Top 10:2025 và hướng dẫn secret scanning kiểm chứng qua nguồn Tier 1 (S99, S100) ngày 2026-07-12. OWASP Top 10 được cập nhật định kỳ (không cố định hàng năm) — khuyến nghị re-verify số phiên bản trước khi xuất bản chính thức nếu khoảng cách thời gian quá xa.