Rà soát bảo mật website một người: danh sách 15 việc làm trong một buổi chiều

Rà soát bảo mật website là gì? Là việc đi qua một danh sách cố định các điểm yếu phổ biến (cấu hình, đăng nhập, phụ thuộc phần mềm, sao lưu, cổng mạng) để tìm và đóng những lỗ hổng dễ thấy nhất. Bài viết gom 15 việc mà người vận hành một mình có thể bắt đầu trong một buổi chiều, dựa trên đợt rà soát và cứng hoá thật của OPCAIOS cho website chạy bằng Next.js, qua Nginx và Cloudflare, theo khung OWASP Top 10:2025. Phần trung thực: đây không phải tư vấn bảo mật chuyên nghiệp, một buổi chiều không đủ để đảm bảo an toàn tuyệt đối, và OPCAIOS không đảm bảo site của mình hay của bạn miễn nhiễm trước tấn công. Danh sách chỉ giúp bạn đóng các cửa hay bị bỏ ngỏ nhất; website có thanh toán, dữ liệu cá nhân nhạy cảm hay lượng khách lớn nên thuê chuyên gia kiểm thử độc lập. Bài không có lệnh tấn công hay lệnh có thể làm hỏng hệ thống; mọi bước đều là kiểm tra và cấu hình phòng thủ.

15 việc chia thành 5 nhóm, làm từ ít rủi ro khi thay đổi đến nhiều. Sơ đồ: OPCAIOS.

Khung tham chiếu OWASP Top 10 là gì?

OWASP (tổ chức phi lợi nhuận về an toàn ứng dụng web) công bố danh sách 10 rủi ro phổ biến. Bản hiện hành trên trang chính thức (đọc ngày 25/10/2026) là OWASP Top 10:2025, gồm: kiểm soát truy cập bị hỏng, cấu hình bảo mật sai, lỗi chuỗi cung ứng phần mềm, lỗi mật mã, injection, thiết kế không an toàn, lỗi xác thực, lỗi toàn vẹn phần mềm hoặc dữ liệu, lỗi ghi log và cảnh báo, và xử lý ngoại lệ sai. Nhiều việc trong danh sách dưới đây rơi đúng vào các nhóm trên (cấu hình, xác thực, chuỗi cung ứng, log). Ví dụ, việc 9 và 10 thuộc nhóm cấu hình bảo mật sai, việc 6 và 7 thuộc nhóm lỗi xác thực, việc 3 và 12 thuộc nhóm chuỗi cung ứng, còn việc 15 thuộc nhóm ghi log và cảnh báo. Hãy dùng danh sách này làm bản đồ để biết mình còn thiếu mảng nào, không phải bảng điểm để "đạt". Đầu tiên, đánh dấu việc đã làm. Tiếp theo, xếp việc chưa làm theo bảng ưu tiên cuối bài. Cuối cùng, rà lại sau mỗi 3 tháng.

Cách sắp xếp buổi chiều

Làm theo thứ tự: việc chỉ xem xét trước, việc thay đổi cấu hình sau, việc rủi ro cao (đổi mạng, nâng cấp framework) cuối cùng và chỉ khi đã có sao lưu. Trước mỗi thay đổi, ghi lại cấu hình cũ để quay lại được.

Nhóm A: trình duyệt và tiêu đề phản hồi

1. Bật Content Security Policy (CSP)

Content Security Policy (CSP) là tiêu đề HTTP cho trình duyệt biết trang được phép tải tài nguyên từ đâu, và mục tiêu chính là giảm tác hại của XSS. Theo MDN (tài liệu đọc ngày 25/10/2026), thứ tự an toàn gồm 3 bước. Đầu tiên, triển khai bằng tiêu đề Content-Security-Policy-Report-Only để chỉ báo cáo. Tiếp theo, xem báo cáo vi phạm và sửa phần hợp lệ. Cuối cùng, chuyển sang tiêu đề Content-Security-Policy để thực thi. MDN cũng khuyên ưu tiên nonce hoặc hash thay vì danh sách tên miền, và tránh 'unsafe-inline' khi có thể. Thực tế của OPCAIOS: website bật CSP có danh sách nguồn cho phép, nhưng bản hiện tại vẫn cho phép script nội tuyến, tức chưa đạt mức nghiêm ngặt MDN khuyến nghị. Hệ quả cần nhớ trên Next.js hay bất kỳ nền tảng nào: mỗi script, iframe hay kết nối ngoài mới đều phải được thêm vào chính sách, nếu không trình duyệt sẽ chặn. Ví dụ giả định: thêm một widget chat mới mà quên khai báo, widget sẽ biến mất.

2. Thêm các tiêu đề bảo mật cơ bản

Chống nhúng trang vào khung lạ (frame-ancestors trong CSP, theo MDN thay thế cho X-Frame-Options), nâng HTTP lên HTTPS cho tài nguyên con, và HSTS. Kiểm tra bằng công cụ xem tiêu đề của trình duyệt.

3. Rà các tài nguyên bên thứ ba

Liệt kê mọi script, font, iframe nhúng từ nơi khác. Bỏ cái không dùng; mỗi cái giữ lại là một nguồn rủi ro chuỗi cung ứng.

Nhóm B: đăng nhập và phiên

4. Kiểm tra Origin cho yêu cầu ghi

Kiểm tra Origin là việc từ chối yêu cầu thay đổi dữ liệu (POST, PUT, DELETE) gửi từ một trang web khác tới phiên đã đăng nhập của bạn. Kiểm soát truy cập bị hỏng đứng đầu các nhóm rủi ro theo OWASP Top 10:2025. OPCAIOS làm kiểm tra Origin ở lớp trung gian của ứng dụng: yêu cầu ghi tới các đường dẫn dùng cookie phải có header Origin cùng máy chủ, nếu không trả mã 403. Webhook và API dùng token được loại trừ có chủ đích, vì các lời gọi ấy không đi qua phiên trình duyệt. Quy trình gồm 3 bước. Đầu tiên, liệt kê các đường dẫn ghi dùng cookie. Tiếp theo, thêm kiểm tra Origin vào lớp trung gian cho đúng các đường dẫn ấy. Cuối cùng, thử một yêu cầu giả từ tên miền khác bằng công cụ như curl và xác nhận nhận được 403. Bài học: khi thêm đường dẫn mới dùng cookie, nhớ đưa vào danh sách được bảo vệ, vì đường dẫn bị quên sẽ không được kiểm tra. Ví dụ, một nút xuất dữ liệu mới trên trang quản trị cần được thêm vào danh sách ngay trong ngày tạo.

5. Giới hạn tốc độ cho đăng nhập và biểu mẫu

Giới hạn tốc độ là việc cho mỗi địa chỉ chỉ được thử một số lần nhất định trong một khoảng thời gian, áp dụng cho đăng nhập và biểu mẫu. Lỗi xác thực là một trong 10 nhóm rủi ro theo OWASP Top 10:2025, và khi vượt ngưỡng ứng dụng nên trả mã 429 (Too Many Requests) kèm header Retry-After. Có 3 chi tiết đáng nhớ. Thứ nhất, gom địa chỉ IPv6 theo dải thay vì từng địa chỉ lẻ, vì một người dùng IPv6 có thể đổi địa chỉ trong cùng dải rất dễ. Thứ hai, dọn dần bộ đếm theo thời gian thay vì xoá sạch một lần, để không vô tình mở lại cửa cho kẻ đang thử mật khẩu. Thứ ba, trả thông báo lỗi chung cho khách thay vì thông điệp kỹ thuật, vì thông điệp chi tiết giúp kẻ tấn công đoán hệ thống. OPCAIOS gom các hàm giới hạn thành tiện ích dùng chung để mọi biểu mẫu mới dùng lại, tránh mỗi nơi tự viết một kiểu. Ví dụ, biểu mẫu đăng ký nhận tài liệu và trang đăng nhập quản trị cùng gọi một hàm giới hạn thay vì hai đoạn mã riêng, nên khi chỉnh ngưỡng chỉ sửa một chỗ.

6. Khoá ký phiên đặt riêng và đủ dài

Cookie phiên và vé xác thực hai bước nên được ký bằng bí mật riêng, ngẫu nhiên, lưu ngoài mã nguồn. Không để giá trị mặc định hay dùng chung khoá với việc khác.

7. Bật xác thực hai bước cho tài khoản quản trị

Và cho cả tài khoản nhà cung cấp quan trọng (tên miền, hosting, email, CDN). Đây là một trong những việc rẻ mà hiệu quả nhất.

8. Chống công thức trong tệp xuất CSV

Nếu trang quản trị cho xuất CSV, ô bắt đầu bằng ký tự đặc biệt có thể bị bảng tính hiểu là công thức. Dùng một hàm chung để vô hiệu hoá khi xuất.

Nhóm C: mạng và hạ tầng

9. Chỉ nhận lưu lượng đi qua CDN

Chỉ nhận lưu lượng đi qua CDN nghĩa là máy chủ gốc chỉ chấp nhận kết nối từ dải địa chỉ của CDN, nên ai gọi thẳng vào địa chỉ máy chủ gốc sẽ bị từ chối. Nếu bạn dùng CDN hoặc lớp bảo vệ phía trước, hãy cấu hình như vậy ở máy chủ web. OPCAIOS làm đúng thế, và nhờ đó yêu cầu gọi thẳng vào địa chỉ gốc nhận mã 403 thay vì được phục vụ. OPCAIOS dùng Cloudflare làm CDN và cấu hình Nginx chỉ nhận dải địa chỉ của Cloudflare. Cấu hình bảo mật sai là một trong 10 nhóm rủi ro theo OWASP Top 10:2025. Hai điều rút ra: Thứ nhất, kiểm tra trực tiếp phải đi qua tên miền chứ không qua địa chỉ máy chủ, vì địa chỉ gốc đã bị chặn. Thứ hai, khi nhà cung cấp CDN đổi dải địa chỉ, danh sách của bạn phải cập nhật theo, nếu không bạn sẽ tự chặn chính mình và khách thật không vào được. Mức rủi ro là cao theo bảng tóm tắt, nên chỉ làm khi đã có sao lưu cấu hình cũ và đường vào dự phòng. Ví dụ giả định: sau khi đổi, hãy thử mở website từ 2 mạng khác nhau để chắc rằng khách vẫn vào được.

10. Đóng cổng thừa

Đóng cổng thừa là việc tắt mọi dịch vụ đang lắng nghe từ Internet mà không cần công khai, vì công cụ quét như Shodan hay Nmap tìm ra các cổng này rất nhanh. Cách làm gồm 3 bước. Đầu tiên, liệt kê những dịch vụ đang lắng nghe từ ngoài internet, ví dụ bảng quản trị, công cụ quản lý container và bảng điều khiển bot. Tiếp theo, với cái nào không cần công khai thì đóng cổng và truy cập qua đường hầm có xác thực. Cuối cùng, kiểm tra lại từ một mạng bên ngoài để chắc cổng đã đóng. Đợt rà soát của OPCAIOS đóng 2 cổng quản trị thừa theo cách trên. Việc đổi tường lửa dễ tự khoá mình khỏi máy chủ, nên giữ sẵn đường vào dự phòng, chẳng hạn bảng điều khiển của nhà cung cấp máy chủ, trước khi đổi. Theo bảng tóm tắt, đây là việc có rủi ro cao nhưng ưu tiên cao, vì cổng quản trị công khai là đích đầu tiên của các công cụ quét tự động. Chỉ làm khi đã có sao lưu và đủ thời gian để xử lý nếu có sự cố.

11. TLS đủ mới

Đặt phiên bản TLS tối thiểu ở mức hiện đại trên CDN hoặc máy chủ (chúng tôi đặt tối thiểu 1.2). Kiểm tra sau khi đổi bằng truy cập thật từ vài thiết bị.

Nhóm D: phần mềm và phụ thuộc

12. Nâng cấp framework và thư viện có lỗ hổng đã công bố

Chạy công cụ kiểm tra phụ thuộc của hệ quản lý gói để xem cảnh báo. OPCAIOS nâng framework lên phiên bản chính mới để hết cảnh báo; việc này làm bằng thư mục triển khai riêng, giữ bản cũ để quay lại. Phân loại cảnh báo: cái ảnh hưởng thời gian chạy xử lý trước, cái chỉ ở công cụ build thì xử lý sau. Nâng cấp phiên bản chính nên làm riêng, không gộp vào buổi chiều nếu bạn chưa có môi trường thử.

13. Bí mật lưu tách khỏi mã

Không để khoá API, mật khẩu trong kho mã. Kiểm tra lịch sử kho mã xem có từng lỡ commit không; nếu có, coi như đã lộ và đổi khoá.

Nhóm E: sao lưu và theo dõi

14. Sao lưu mã hoá, ra ngoài máy chủ, và thử khôi phục

Sao lưu định kỳ, mã hoá trước khi đưa lên nơi lưu ngoài, giữ nhiều bản theo thời gian. Quan trọng nhất: thử khôi phục thật ít nhất một lần, và cất cụm mật mã ở hai nơi riêng biệt, vì mất cả hai là sao lưu thành vô dụng. OPCAIOS làm đúng như vậy, gồm cả bước thử khôi phục.

15. Có log và cảnh báo tối thiểu

OWASP xếp việc thiếu ghi log và cảnh báo thành một hạng mục riêng. Tối thiểu: lưu log truy cập và lỗi, có thông báo khi dịch vụ ngừng, và có cách xem ai đã đăng nhập quản trị khi nào. Một lịch kiểm tra định kỳ (hàng quý) cũng nên nằm trong danh sách.

Bảng tóm tắt 15 việc

#	Việc	Rủi ro khi làm	Ưu tiên
1	CSP (báo cáo trước)	Trung bình, có thể chặn nhầm	Cao
2	Tiêu đề bảo mật khác	Thấp	Trung bình
3	Rà bên thứ ba	Thấp	Trung bình
4	Kiểm tra Origin	Trung bình	Cao
5	Giới hạn tốc độ	Thấp	Cao
6	Khoá ký phiên	Thấp (đăng xuất người dùng)	Cao
7	Xác thực hai bước	Thấp	Rất cao
8	Chống công thức CSV	Thấp	Thấp
9	Chỉ nhận qua CDN	Cao	Cao
10	Đóng cổng thừa	Cao	Cao
11	TLS tối thiểu	Trung bình	Trung bình
12	Nâng cấp phụ thuộc	Cao	Cao
13	Bí mật tách khỏi mã	Thấp	Rất cao
14	Sao lưu mã hoá + thử khôi phục	Thấp	Rất cao
15	Log và cảnh báo	Thấp	Trung bình

Kinh nghiệm của OPCAIOS

Chúng tôi làm đợt rà soát này bằng cách để tác tử AI đọc mã và cấu hình, đề xuất sửa, người chủ duyệt rồi áp dụng; sau đó đóng từng hạng mục và kiểm tra lại. Vài điều rút ra:

• Sửa trong mã (CSP, Origin, giới hạn tốc độ) làm nhanh và dễ hoàn tác; sửa ở hạ tầng (mạng, CDN, tường lửa) cần người có quyền và dễ tự khoá mình.
• Đừng gỡ CSP hay kiểm tra Origin khi "có gì đó ngừng chạy"; hãy tìm nguồn bị chặn và thêm đúng chỗ.
• Một buổi rà soát chỉ là điểm bắt đầu. Chúng tôi không tuyên bố site mình miễn nhiễm, và không có kết quả kiểm thử xâm nhập độc lập để công bố. Muốn hiểu rộng hơn về dữ liệu khi dùng AI, xem bảo mật dữ liệu kinh doanh khi dùng AI.

Liên quan: nếu bạn tự dựng máy chủ, xem cài đặt n8n trên VPS; về pháp lý khi kinh doanh một người, xem checklist pháp lý đăng ký kinh doanh solopreneur; về cách chúng tôi vận hành, xem hệ thống AI vận hành một mình.

Câu hỏi thường gặp

Một buổi chiều có đủ để website an toàn không?

Không. Đủ để đóng các lỗi cấu hình phổ biến nhất, nhưng an toàn là quá trình liên tục (cập nhật, theo dõi, rà lại định kỳ). Đây không phải tư vấn bảo mật chuyên nghiệp.

Nên làm việc nào đầu tiên?

Xác thực hai bước, bí mật tách khỏi mã, và sao lưu có thử khôi phục: ba việc rẻ, rủi ro thấp, hiệu quả cao. Sau đó mới tới CSP và các thay đổi hạ tầng.

CSP có làm hỏng website không?

Có thể, nếu bật thực thi ngay. Theo MDN, hãy bắt đầu bằng chế độ chỉ báo cáo, xem vi phạm, sửa rồi mới chuyển sang thực thi.

Có cần thuê chuyên gia không?

Nếu site có thanh toán, dữ liệu cá nhân nhạy cảm, hoặc yêu cầu tuân thủ, nên có kiểm thử độc lập. Danh sách này không thay thế việc đó.

Tôi mới bắt đầu, nên học gì thêm?

Đọc danh sách OWASP Top 10 và tài liệu chính thức của nền tảng bạn dùng, rồi thực hành từng mục trên môi trường thử. Nếu cần lộ trình ứng dụng AI vào công việc kỹ thuật một cách an toàn, có thể tham khảo khoá đào tạo ứng dụng AI của OPCAIOS.

Nguồn: OWASP Top 10:2025 (top10.owasp.org) và tài liệu MDN về Content Security Policy (đọc ngày 25/10/2026); điều chưa kiểm chứng: hiệu quả thực tế của từng biện pháp với site của bạn, tài liệu chính thức về TLS và HSTS chưa được đọc trong lần viết này; Kinh nghiệm là của OPCAIOS.