Checklist bảo mật Claude Code cho rà soát nhanh web app

Kiểm tra bảo mật nhẹ là gì

Kiểm tra bảo mật nhẹ là một rà soát nhanh (thường 30–60 phút) nhằm phát hiện các vấn đề rõ ràng, tác động cao trước khi đưa ra sản phẩm. Đây không phải là một cuộc audit đầy đủ. Hãy nghĩ nó như một lần đi kiểm tra an toàn: bạn quét những con đường thường hỏng trong các app thực tế và tìm bằng chứng, không phải đoán mò.

Checklist bảo mật Claude Code này tập trung vào các vùng hay hỏng nhất trong các web app hàng ngày:

• Giả định xác thực (cách bạn biết người dùng là ai)
• Lỗ hổng phân quyền (họ được phép làm gì)
• Xác thực đầu vào
• Quản lý secrets
• Các bề mặt injection phổ biến (SQL, thực thi lệnh, render template, chuyển hướng, upload)

Nó không cố chứng minh không có lỗi, mô hình hóa các tác nhân đe dọa phức tạp, hay thay thế kiểm thử xâm nhập.

"Kết luận cụ thể" nghĩa là mọi vấn đề bạn ghi lại đều có bằng chứng để dev có thể hành động ngay. Với mỗi phát hiện, ghi lại:

• Tệp chính xác và tên hàm/handler
• Hành vi rủi ro trong một câu
• Bước tái tạo tối thiểu (request, payload, hoặc đường dẫn click)
• Tại sao nó quan trọng (tác động) và ai có thể kích hoạt
• Hướng sửa an toàn (không cần viết lại toàn bộ)

AI là trợ thủ, không phải thẩm quyền cuối cùng. Dùng nó để tìm kiếm, tóm tắt và đề xuất kiểm thử. Sau đó xác minh bằng cách đọc mã và, nếu có thể, tái tạo bằng request thực. Nếu mô hình không chỉ ra vị trí và bước cụ thể, coi tuyên bố đó chưa được chứng minh.

Thiết lập phạm vi trong 10 phút

Rà soát nhanh chỉ hiệu quả nếu bạn thu hẹp mục tiêu. Trước khi yêu cầu Claude Code xem gì, quyết định hôm nay bạn muốn chứng minh điều gì và không kiểm tra gì.

Bắt đầu với 1 đến 3 hành trình người dùng thực mà lỗi ở đó gây mất tiền, lộ dữ liệu, hoặc cho quyền lực. Ứng viên tốt là đăng nhập, đặt lại mật khẩu, thanh toán, và màn hình chỉnh sửa admin.

Tiếp theo, nêu rõ tài sản bạn phải bảo vệ. Cụ thể: tài khoản người dùng, hành động thanh toán, dữ liệu cá nhân, thao tác chỉ dành cho admin.

Rồi viết ra giả định đe dọa bằng từ ngữ đơn giản. Bạn đang phòng thủ trước người dùng tò mò click lung tung, kẻ tấn công bên ngoài có script, hay nội bộ có một phần quyền? Câu trả lời thay đổi tiêu chuẩn “đủ tốt”.

Cuối cùng, định nghĩa pass và fail để kiểm tra kết thúc bằng các phát hiện, không phải cảm nhận. Quy tắc đơn giản thường hiệu quả:

• Pass: mọi hành động nhạy cảm có kiểm tra authn và authz rõ ràng.
• Fail: bất kỳ endpoint nào tin vào client về user ID hoặc role.
• Pass: input được validate phía server, không chỉ ở UI.
• Fail: secrets xuất hiện trong logs, config, hoặc mã client.

Nếu bạn không mô tả được thất bại trông như thế nào, phạm vi vẫn còn mơ hồ.

Chuẩn bị ngữ cảnh bạn cung cấp cho Claude Code

Kiểm tra chỉ hiệu quả khi mô hình nhìn đúng chỗ. Gom một gói mã và ghi chú nhỏ để rà soát tạo ra bằng chứng, không phỏng đoán.

Bắt đầu bằng việc chia sẻ đường dẫn bảo mật quan trọng: điểm vào của request và mã quyết định ai là người dùng và họ được làm gì. Kèm đủ mã xung quanh để thấy luồng dữ liệu.

Một gói thực tế thường gồm:

• Điểm vào auth: phân tích session/JWT, cài cookie, callback login, middleware auth
• Routes + handlers: controllers, RPC methods, GraphQL resolvers, handlers job nền
• Lớp dữ liệu: truy vấn ORM, helper SQL thô, query builder, migrations cho bảng nhạy cảm
• Kiểm tra chính sách: kiểm tra role, kiểm tra ownership, feature flag, endpoint chỉ admin
• Xác thực: schema validator request, handler upload file, mã deserialize

Thêm vài dòng ghi chú môi trường để giả định rõ ràng: session vs JWT, token nằm ở đâu (cookie hay header), reverse proxy hoặc API gateway, queue/cron worker, và bất kỳ endpoint "chỉ nội bộ" nào.

Trước khi đi tìm bug, yêu cầu một inventory: điểm vào, endpoint đặc quyền, và datastore bị chạm tới. Điều này tránh bỏ sót bề mặt.

Cũng thống nhất định dạng đầu ra ép buộc kết luận cụ thể. Một bảng đơn giản hiệu quả: Finding, Severity, Endpoint/file bị ảnh hưởng, Evidence (đoạn snippet hoặc khoảng dòng), Kịch bản khai thác, Gợi ý sửa.

Quy trình từng bước cho rà soát 30–60 phút

Giới hạn thời gian:

• 10 phút để định hướng
• 15–30 phút để truy vết luồng
• 10 phút để viết báo cáo

Mục tiêu không phải phủ đầy. Là một vài phát hiện có thể kiểm thử.

Mở app khi đọc mã. Click qua UI và quan sát request. Ghi chú phải chỉ tới endpoint cụ thể, tham số và nguồn dữ liệu.

Quy trình phù hợp trong một lần ngồi:

1. Phác thảo điểm vào và ranh giới tin cậy. Ghi route công khai, route yêu cầu login, route admin, webhook, upload, và callback bên thứ ba. Đánh dấu nơi dữ liệu chuyển từ do người dùng kiểm soát sang server tin tưởng.
2. Với mỗi endpoint quan trọng, ghi nơi chứng minh danh tính và chỗ đó xảy ra. Nếu kiểm tra là "middleware", xác nhận mọi route thực sự dùng nó.
3. Lặp lại cho phân quyền. Chọn một hành động rủi ro (xem dữ liệu người khác, cập nhật role, export, xóa) và truy vết quyết định quyền cho tới truy vấn DB.
4. Truy vết input người dùng tới sinks. Theo một tham số từ request tới SQL/ORM, render template, thực thi lệnh, fetch URL (SSRF), redirect, và đường dẫn file.
5. Quét luồng secrets khi truy vết. Tìm token trong logs, mã client-side, thông báo lỗi, dump môi trường, và mẫu lưu trữ yếu.

Thói quen hữu ích: với mỗi "có vẻ ổn", viết cách bạn sẽ phá nó. Nếu không mô tả được cách phá, bạn có thể chưa xác minh đủ.

Kiểm tra Authn: chứng minh người dùng là ai

Xác thực là nơi app quyết định, “request này thuộc về người này.” Kiểm tra nhanh không phải đọc mọi dòng. Là tìm chỗ danh tính được thiết lập lần đầu, rồi kiểm tra đường tắt và đường hỏng.

Xác định ranh giới tin cậy: danh tính được tạo hoặc chấp nhận ở đâu? Có thể là cookie session, token JWT bearer, API key, hoặc mTLS tại edge. Yêu cầu Claude Code chỉ ra file và hàm cụ thể biến “anonymous” thành user id, và liệt kê mọi đường khác có thể làm điều tương tự.

Các kiểm tra Authn đáng rà soát:

• Xác định mọi điểm vào auth (web login, API token, mobile auth, auth service nội bộ) và xác nhận chúng hội tụ về một mô hình danh tính nhất quán.
• Kiểm tra login và đặt lại mật khẩu về rate limit, lockout, và user enumeration (lỗi hoặc thời gian trả lời khác nhau giữa account tồn tại và không tồn tại).
• Kiểm tra session và cookie: HttpOnly, Secure, SameSite, expiry, rotation khi login và khi thay đổi đặc quyền, và invalidation khi logout (phía server, không chỉ “xóa cookie”).
• Kiểm tra MFA và recovery để đường phục hồi không yếu hơn MFA (ví dụ đặt lại chỉ bằng email mà bỏ qua MFA).
• Kiểm tra logging thất bại xác thực: hữu ích cho ops, nhưng không lộ chi tiết giúp kẻ tấn công (không cho biết “user tồn tại”, không dump token).

Ví dụ thực tế: nếu email reset trả về “account not found” thì đó là vấn đề enumeration nhanh. Ngay cả thông điệp chung, khác biệt thời gian cũng có thể rò rỉ, nên kiểm tra thời gian phản hồi.

Kiểm tra Authz: chứng minh người dùng được phép

Phân quyền là câu hỏi gây hại nhiều nhất khi sai: “Người này có phép làm hành động này trên tài nguyên này không?” Kiểm tra nhanh cố gắng phá giả định đó có chủ ý.

Viết role và quyền bằng ngôn ngữ đơn giản, dễ hiểu:

• Owner có thể mời thành viên
• Member có thể chỉnh hồ sơ của họ
• Support có thể xem chi tiết thanh toán nhưng không đổi gói
• Admin có thể xóa project

Rồi xác minh mọi hành động nhạy cảm thực thi authz trên server, không chỉ ở UI. Nút có thể ẩn, route có thể khóa ở client, nhưng kẻ tấn công vẫn gọi API trực tiếp.

Quét nhanh thường tìm thấy vấn đề thực:

• Tìm endpoint/mutation tạo, xóa, export, thay role, hoặc truy cập billing
• Với mỗi cái, tìm kiểm tra quyền phía server (không phải frontend)
• Tìm ID do user kiểm soát (projectId, userId, orgId) và xác nhận kiểm tra ownership
• Xác nhận đường dẫn chỉ admin phải fail closed khi role thiếu
• Kiểm tra ranh giới tenant: orgId/accountId phải lấy từ context session, không chỉ từ input request

Mùi IDOR cổ điển: request như GET /projects/{id} nơi {id} do user điều khiển, và server load nó mà không xác minh thuộc user hoặc tenant hiện tại.

Một prompt ép mô tả thực tế:

“Với endpoint này, chỉ ra mã chính xác quyết định truy cập, và liệt kê điều kiện cụ thể có thể khiến user từ orgId khác truy cập được. Nếu không, giải thích vì sao với tên file và hàm.”

Xác thực đầu vào: giữ dữ liệu xấu ngoài sớm

Hầu hết vấn đề web app bắt nguồn từ một khoảng trống: app chấp nhận input dev không mong đợi. Xem “input” là bất cứ thứ gì người dùng hoặc hệ thống khác có thể ảnh hưởng, dù cảm thấy vô hại.

Bắt đầu bằng việc ghi tên các input cho endpoint bạn kiểm tra:

• Giá trị query và path trong URL
• Trường body request (kể cả JSON lồng nhau)
• Header (auth header, content type, forwarded IP)
• Cookie
• Upload file (tên, kích thước, loại, metadata)

Validation nên xảy ra gần nơi dữ liệu vào app, không nằm sâu trong business logic. Kiểm tra cơ bản: kiểu (string hay number), độ dài tối đa, required vs optional, và định dạng (email, UUID, date).

Với giá trị đã biết như role, status, hay hướng sắp xếp, ưu tiên allowlist. Dễ hơn để chống vượt qua so với “chặn vài giá trị xấu”.

Cũng kiểm tra xử lý lỗi. Nếu app từ chối input, đừng echo giá trị thô lại trong response, logs, hoặc UI. Đó là cách các lỗi xác thực nhỏ trở thành rò rỉ dữ liệu hoặc trợ giúp injection.

Kế hoạch “input xấu” cho các endpoint rủi ro (login, search, upload, hành động admin):

• Chuỗi quá dài (10.000+ ký tự)
• Kiểu sai (mảng thay vì chuỗi)
• Giá trị enum bất ngờ
• Ký tự đặc biệt thay đổi nghĩa
• Giá trị rỗng cho trường bắt buộc

Ví dụ: tham số sort chấp nhận bất kỳ chuỗi nào có thể trở thành mảnh SQL sau đó. Một allowlist như "date" hoặc "price" ngăn loại lỗi này sớm.

Các bề mặt injection phổ biến để rà nhanh

Hầu hết rà soát nhanh tìm vấn đề ở vài chỗ giống nhau: nơi input người dùng được hiểu như mã, truy vấn, đường dẫn, hoặc URL. Đây là nơi săn các khoảnh khắc “input vượt ranh giới tin cậy”.

Theo dấu dữ liệu từ điểm vào (query params, headers, cookies, upload, form admin) tới nơi nó kết thúc.

Mục tiêu quét nhanh

Tìm các mẫu sau và yêu cầu ví dụ payload/call site cụ thể cho mỗi loại:

• SQL injection: query nối chuỗi, ORDER BY động, và builder IN (...) nối các giá trị người dùng
• XSS: render HTML, template, preview markdown, rich text editor khi “sanitize sau” được giả định
• Command injection: gọi shell quanh xử lý ảnh, công cụ PDF, backup, hoặc bước “convert” truyền flag do người dùng cung cấp
• SSRF: fetch URL cho webhook, preview link, import từ URL, và kiểm tra nội bộ chấp nhận URL từ user
• Path traversal: endpoint download file, giải nén zip, pipeline upload sau đó đọc file theo tên

Cũng chú ý deserialization và template injection. Bất cứ thứ gì parse JSON/YAML do user cung cấp hoặc chuỗi template có thể ẩn hành vi rủi ro, nhất là khi hỗ trợ type tùy chỉnh, biểu thức, hoặc render phía server.

Nếu một feature chấp nhận URL, filename, hay text định dạng, giả định nó có thể bị lạm dụng cho tới khi bạn chứng minh ngược lại bằng mã và test.

Quản lý secrets: tìm rò rỉ và lưu trữ yếu

Vấn đề secrets thường rõ ràng khi biết chỗ để tìm. Tập trung vào nơi secrets sống và nơi chúng bị sao chép vô tình.

Những nơi secrets hay xuất hiện:

• Biến môi trường và file config app
• Output CI và log build (kể cả log deploy thất bại)
• Gói client và build mobile (bất cứ thứ gì phát hành tới người dùng)
• Endpoint debug, trang health, và công cụ admin
• Trang lỗi, stack trace, và event analytics

Rồi hỏi câu cụ thể: nếu một secret bị lộ hôm nay, chuyện gì xảy ra tiếp theo? Hệ thống tốt có đường xoay khóa (phát key mới), revoke (vô hiệu key cũ), và cách redeploy nhanh. Nếu câu trả lời là “sau này mới đổi”, coi đó là một phát hiện.

Nguyên tắc least privilege là chiến thắng nhanh. Khóa quá quyền khiến sự cố nặng hơn. Tìm user DB có thể drop table, token bên thứ ba có thể quản lý account, hoặc API key dùng chung giữa môi trường. Ưu tiên một key cho mỗi service, mỗi môi trường, với quyền ít nhất cần thiết.

Prompt rà soát nhanh bạn có thể dán vào Claude Code:

• “Tìm chuỗi token, mật khẩu, private key cứng trong repo. Liệt kê đường dẫn file chính xác và mẫu chuỗi bạn khớp.”
• “Tìm mã log header request, cookie, env var, hoặc object lỗi đầy đủ. Hiển thị dòng log và trường nhạy cảm có thể xuất hiện.”
• “Kiểm tra xem secrets có thể vào snapshot, export, hay artifact build không. Xác định gì bị capture và lưu ở đâu.”

Cuối cùng, xác nhận guardrail: chặn secrets khỏi source control (pre-commit/CI checks), và đảm bảo backup/snapshot không chứa credentials plain-text. Nếu nền tảng hỗ trợ snapshot và rollback, kiểm tra secrets được inject tại runtime, không bake vào image lưu sẵn.

Prompts ép ra kết luận cụ thể (mẫu copy-paste)

Prompt mơ hồ cho trả lời mơ hồ. Ép mô hình cam kết bằng chứng: vị trí chính xác, trace bạn có thể theo, repro bạn chạy được, và điều gì làm tuyên bố sai.

Dùng một mẫu tại một thời điểm, rồi yêu cầu sửa sau khi bạn xác nhận hoặc từ chối chi tiết.

• Bằng chứng cấp file: “Tìm repo cho auth, sessions, tokens, middleware. Nêu file, hàm, và khoảng dòng chính xác. Trích đoạn liên quan. Nếu không chỉ ra mã, hãy trả lời ‘no evidence found’.”
• Trace từ input tới sink: “Chọn một input do user kiểm soát (header, query, body, cookie). Hiện luồng dữ liệu từng bước từ điểm vào tới nơi dùng (SQL, HTML, shell, template, redirect, file path). Liệt kê mỗi hàm trong chuỗi.”
• Bước tái tạo: “Cho repro tối thiểu bằng curl (method, cấu trúc URL, header, body). Bao gồm mã trạng thái mong đợi và ví dụ response thành công/thất bại. Nêu giả định (role, trạng thái auth).”
• Kiểm soát false-positive: “Cái gì sẽ bác bỏ phát hiện này? Liệt kê 2–3 kiểm tra: config flags, thứ tự middleware, validate allowlist, parameterized queries, escape của framework. Nếu có mặt, giải thích vì sao rủi ro thay đổi.”
• Sửa nhỏ nhất an toàn + test: “Đề xuất thay đổi nhỏ nhất chặn lỗi mà không phá trường hợp hợp lệ. Viết một test để thêm (tên, ý định, input, kết quả mong đợi). Nếu có trade-off, nêu rõ.”

Nếu output vẫn mơ hồ, khóa lại:

“Trả lời chỉ với: đường dẫn file, tên hàm, dòng rủi ro, và một câu tác động.”

Ví dụ thực tế: biến linh cảm thành vấn đề đã được xác minh

Các endpoint cập nhật profile thường ẩn lỗi kiểm soát truy cập. Đây là kịch bản bạn có thể chạy qua checklist.

Kịch bản: endpoint API cập nhật profile user:

PATCH /api/profile?accountId=123 với JSON như { "displayName": "Sam" }.

Bạn yêu cầu Claude Code tìm handler, truy vết cách accountId được dùng, và chứng minh server enforce ownership hay không.

Thường thấy:

• Authn: request yêu cầu session hoặc token, nên có vẻ bảo vệ.
• Authz: handler tin accountId từ query string và cập nhật account đó mà không kiểm tra nó có khớp user đã xác thực không.
• Xác thực input: displayName được trim, nhưng accountId không validate là số.
• Bề mặt injection: SQL được xây bằng nối chuỗi như "... WHERE account_id=" + accountId.

Báo cáo tốt là cụ thể:

• Mức độ: Cao (IDOR + khả năng SQL injection)
• Bằng chứng: request với login hợp lệ thay đổi user khác khi chỉnh accountId; SQL xây từ input không tin cậy
• Sửa: bỏ qua accountId từ client, dùng account id của user đã xác thực ở server; parameterize query
• Test: cố gắng update account khác và mong 403; từ chối accountId không phải số

Sau khi patch, rà nhanh lại:

• Thử cùng request với accountId khác và xác nhận thất bại.
• Xác nhận logs cho thấy server dùng id đã xác thực, không phải query param.
• Xác nhận query dùng placeholder/param, không nối chuỗi.
• Chạy test phủ input sai (chữ, số rất lớn).

Bẫy thường khiến kiểm tra nhanh bỏ sót lỗi thật

Cách nhanh nhất để bỏ qua lỗ hổng là tin vào những gì UI áp đặt. Nút ẩn hay disable không phải kiểm tra quyền. Nếu server vẫn chấp nhận request, ai cũng có thể replay với user ID khác, role khác, hoặc gọi API trực tiếp.

Một sai lầm khác là yêu cầu mơ hồ. “Làm review bảo mật” thường cho báo cáo chung chung. Kiểm tra nhanh cần phạm vi chặt (endpoint nào, role nào, dữ liệu nào) và định dạng đầu ra nghiêm (tên file, hàm, dòng rủi ro, repro tối thiểu).

Quy tắc tương tự cho output AI: không chấp nhận tuyên bố nếu không chỉ ra code location và bước kích hoạt. Nếu phát hiện không có location mã cụ thể và cách kích hoạt từng bước, coi đó là chưa được chứng minh.

Cách kiểm tra nhanh lệch hướng

Những bẫy này lặp lại:

• Giả định “chỉ admin” vì đó là trang admin, không vì server enforce
• Yêu cầu kết quả rộng thay vì “chỉ cho request chính xác bypass X”
• Chấp nhận “có thể SQL injection” mà không có điểm xây query và đường input
• Bỏ qua điểm vào ít rõ ràng như webhook, scheduled job, import tool, và hành động admin nội bộ
• Vá triệu chứng (thêm filter hoặc regex) trong khi nguyên nhân gốc là thiếu validate hoặc phân quyền

Nếu bạn thấy mình thêm filter cho mọi edge case, dừng lại. Sửa thường ở ranh giới: validate input sớm, và tập trung phân quyền nên rõ ràng, tập trung để mọi đường đi dùng chung.

Kiểm tra nhanh trước khi phát hành bạn có thể chạy

Những kiểm tra này không thay audit đầy đủ, nhưng bắt lỗi dễ lọt khi mọi người mệt. Giữ chúng tập trung vào cái bạn chứng minh nhanh: một request gửi được, một trang load, một dòng log tìm thấy.

Năm kiểm tra nhanh thường có hiệu quả:

• Ma sát Authn: Thử 10 lần login sai liên tiếp. Bạn thấy rate limit, lockout, hoặc ít nhất chậm lại? Có thể phân biệt email tồn tại từ thông báo lỗi hay thời gian trả lời không?
• Authz bằng đổi ID: Chọn tài nguyên thực (order, invoice, profile). Thay ID trong URL, body JSON, hoặc biến GraphQL. Bạn nhận được dữ liệu không phải của bạn, kể cả metadata?
• Hàng rào input: Với trường quan trọng (email, tên, search, upload), thử chuỗi rất dài, Unicode lạ, và kiểu không mong đợi (số thay vì chuỗi). Bạn có enforce giới hạn độ dài và allowlist nơi cần?
• Lộ secrets: Tìm nhanh logs và gói client cho token, API key, JWT, hoặc header “Authorization: Bearer”. Kiểm tra trang lỗi nữa. “Chỉ ở staging” thường thành “đã phát hành”.
• Bề mặt injection: Tìm nối chuỗi vào SQL, filter, template render, lệnh shell, hoặc redirect URL. Nếu input đến một trong những nơi này mà không có validate mạnh, giả định rủi ro cho tới khi chứng minh.

Viết 3 sửa hàng đầu bạn có thể ship trong tuần, không phải danh sách mong ước. Ví dụ: (1) thêm rate limit cho login và reset mật khẩu, (2) enforce ownership server-side cho endpoint “get by id”, (3) giới hạn độ dài input và từ chối ký tự không mong muốn cho field search.

Bước tiếp theo: biến checklist này thành một bước trong quy trình build

Kiểm tra chỉ có ích khi kết quả làm thay đổi những gì bạn ship. Đối xử checklist này như một bước nhỏ, có thể lặp trong quy trình build, không phải cứu cánh một lần.

Biến mọi phát hiện thành item backlog khó hiểu sai:

• Fix: thay đổi gì trong code hoặc config
• Test: cách bạn chứng minh đã sửa (một request, một unit test, một bước QA)
• Owner: một người chịu trách nhiệm
• Target date: release tiếp theo hoặc ngày cụ thể
• Evidence: file/endpoint và request/payload chính xác đã cho thấy vấn đề

Chọn tần suất phù hợp với rủi ro và quy mô team. Với nhiều team, mỗi release là tốt nhất. Nếu release thường xuyên, làm rà soát 30–60 phút hàng tháng và một check ngắn trước khi phát hành.

Làm dễ lặp lại bằng cách tạo gói prompt tái sử dụng và mẫu checklist. Giữ prompt tập trung vào đầu ra cụ thể: show route, guard, request failing, và hành vi mong đợi. Lưu gói ở chỗ team đã làm việc để không bị bỏ quên.

Nếu bạn xây app qua chat, nhúng checklist vào kế hoạch. Thêm ghi chú “giả định bảo mật” ngắn cho authn/authz, input, và secrets, rồi chạy spot-check ngay sau phiên bản đầu chạy được.

Nền tảng như Koder.ai (koder.ai) có thể phù hợp vì cho phép lặp nhanh trong khi giữ các điểm kiểm tra. Dùng snapshot và rollback quanh thay đổi rủi ro giúp deploy fix bảo mật dễ hơn mà không bị kẹt khi thay đổi phá vỡ hành vi.