Bảo mật API cho web app: 8 lỗi OWASP thường gặp nhất

Bạn đã bao giờ thử đổi con số trong đường link api/orders/1001 thành 1002 và bất ngờ thấy hiện ra đơn hàng của người khác chưa? Nếu có, chúc mừng — bạn vừa chạm tay vào một trong những lỗi bảo mật API phổ biến nhất thế giới, và nó đang tồn tại trong hàng nghìn web app mà chủ nhân của chúng không hề hay biết. Ngày nay, mọi web app hiện đại — từ website bán hàng, app mobile đến hệ thống ERP — đều giao tiếp qua API. Giao diện chỉ là "mặt tiền", còn API mới là cánh cửa thật dẫn vào dữ liệu. Bài viết này tổng hợp 8 lỗi bảo mật API thường gặp nhất theo chuẩn OWASP API Security Top 10 phiên bản 2023, kèm ví dụ minh họa và hướng khắc phục cụ thể.

Bảo mật api owasp: vì sao API là "cửa ngõ" bị tấn công nhiều nhất của web app hiện nay?

API (Application Programming Interface) là tập hợp các điểm truy cập cho phép ứng dụng giao tiếp với nhau: app mobile lấy dữ liệu từ server, website gọi dịch vụ thanh toán, CRM đồng bộ với kho hàng. Một web app trung bình có hàng chục, thậm chí hàng trăm endpoint API — mỗi endpoint là một cánh cửa tiềm năng.

Vấn đề là API được thiết kế để máy móc gọi nhau, không phải để con người nhìn. Trong khi giao diện có phân quyền hiển thị rõ ràng ("người dùng thường không thấy nút xóa"), API lại phơi bày toàn bộ logic ở tầng dữ liệu. Chỉ cần một endpoint thiếu kiểm tra phân quyền, kẻ tấn công có thể đọc, sửa, xóa dữ liệu của người khác mà không cần vượt qua giao diện.

OWASP — tổ chức phi lợi nhuận uy tín toàn cầu về bảo mật ứng dụng web — đã xuất bản riêng tài liệu OWASP API Security Top 10 (bản mới nhất 2023, bản đầu ra mắt 2019): danh sách 10 rủi ro bảo mật API nghiêm trọng nhất từ kinh nghiệm thực tế của cộng đồng chuyên gia toàn cầu. 8 lỗi dưới đây là những mục developer Việt Nam hay mắc phải nhất.

Bảo mật api owasp: lỗi 1 — API1:2023: Phân quyền cấp đối tượng bị hỏng (BOLA/IDOR)

BOLA (Broken Object Level Authorization), còn gọi là IDOR, là lỗi đứng đầu OWASP API Security 2023. Cơ chế rất đơn giản: API nhận một ID đối tượng từ người dùng (ví dụ /api/users/123/profile) nhưng quên kiểm tra xem user đang đăng nhập có quyền truy cập đối tượng đó hay không.

Ví dụ minh họa: web app bán hàng có API GET /api/invoices/5001 trả về hóa đơn. Kẻ tấn công đổi thành 5002, 5003... và đọc được hóa đơn của người dùng khác — kèm tên, địa chỉ, số điện thoại. Không cần kỹ thuật cao siêu, chỉ cần đoán ID.

Cách khắc phục: "không bao giờ tin ID từ client" — mọi endpoint truy cập đối tượng theo ID đều phải kiểm tra quyền sở hữu phía server. Triển khai kiểm tra phân quyền tập trung (middleware/policy) thay vì để mỗi developer tự nhớ, và dùng ID ngẫu nhiên khó đoán (UUID) thay cho ID tăng dần 1, 2, 3...

Bảo mật api owasp: lỗi 2 — API2:2023: Cơ chế xác thực bị hỏng

Xác thực (authentication) là bước xác định "bạn là ai" trước khi cho phép gọi API. Lỗi API2 xảy ra khi cơ chế này triển khai sai: không giới hạn brute-force mật khẩu, token sống quá lâu, chấp nhận token giả mạo, hoặc endpoint "quên mật khẩu" bị lợi dụng chiếm tài khoản.

Ví dụ minh họa: API đăng nhập không giới hạn số lần thử — kẻ tấn công dùng công cụ tự động thử hàng nghìn mật khẩu phổ biến vào tài khoản admin. Hoặc API dùng JWT nhưng server không kiểm tra chữ ký đúng cách, attacker tự tạo token quyền admin và API tin luôn.

Cách khắc phục: giới hạn số lần đăng nhập sai (rate limiting), khóa tạm tài khoản sau nhiều lần thất bại; đặt access token sống ngắn (15–30 phút) kèm refresh token; luôn kiểm tra chữ ký JWT phía server; bật xác thực đa yếu tố (MFA) cho tài khoản quản trị; thông báo lỗi đăng nhập không tiết lộ "email này tồn tại".

Lỗi 3 — API3:2023: Phân quyền cấp thuộc tính đối tượng bị hỏng

Nếu BOLA là "đọc nhầm đối tượng của người khác", thì API3 tinh vi hơn: attacker truy cập đúng đối tượng của mình nhưng đọc/sửa được những thuộc tính không dành cho mình. OWASP 2023 gộp hai lỗi cũ (Excessive Data Exposure và Mass Assignment) thành một nhóm vì cùng nguyên nhân: thiếu kiểm tra phân quyền ở cấp thuộc tính.

Ví dụ minh họa: API GET /api/users/me trả về toàn bộ object user gồm cả is_admin, salary — frontend chỉ hiển thị tên và email, nhưng attacker xem raw response là thấy hết. Nguy hiểm hơn là Mass Assignment: attacker thêm "is_admin": true vào body của PUT /api/users/me, server gán trực tiếp vào database mà không lọc — attacker tự nâng quyền admin.

Cách khắc phục: API chỉ trả về đúng các trường mà vai trò đó được phép thấy; đầu vào dùng whitelist các trường được phép cập nhật; không bao giờ bind trực tiếp request body vào model dữ liệu.

Lỗi 4 — API4:2023: Tiêu thụ tài nguyên không giới hạn

Mỗi request API đều tiêu tốn tài nguyên server: CPU, RAM, băng thông — thậm chí tiền thật khi API gọi sang dịch vụ bên thứ ba tính phí theo lượt (SMS OTP, email). Lỗi API4 là khi API không giới hạn mức tiêu thụ, để attacker gửi request "nặng" hoặc lặp lại liên tục gây sập dịch vụ (DoS) hoặc đội chi phí.

Ví dụ minh họa: endpoint tìm kiếm cho phép limit=999999999 khiến database quét toàn bộ bảng; endpoint gửi OTP không giới hạn số lần gọi, attacker spam hàng chục nghìn SMS khiến doanh nghiệp nhận hóa đơn "trên trời". Theo OWASP, tấn công thành công có thể gây từ chối dịch vụ hoặc đội chi phí vận hành nghiêm trọng.

Cách khắc phục: giới hạn phân trang tối đa (ví dụ 100 bản ghi); rate limiting theo IP, user và endpoint — đặc biệt chặt với endpoint tốn kém (OTP, upload, export); giới hạn kích thước request body; với API tính phí theo lượt, đặt ngưỡng cảnh báo chi phí.

Lỗi 5 — API5:2023: Phân quyền cấp chức năng bị hỏng

Khác với BOLA (sai ở cấp đối tượng), API5 sai ở cấp chức năng: attacker gọi được endpoint chỉ dành cho vai trò cao hơn — ví dụ user thường gọi được API xóa tài khoản của admin.

Ví dụ minh họa: endpoint DELETE /api/admin/users/{id} dành cho quản trị viên nhưng developer quên kiểm tra quyền — tài khoản thường cũng xóa được tài khoản bất kỳ. Biến thể phổ biến: frontend ẩn nút "quản trị" với user thường, nhưng API đằng sau vẫn mở; attacker bỏ qua giao diện, gọi API trực tiếp.

Cách khắc phục: mọi endpoint hành chính phải kiểm tra vai trò phía server; tách nhóm endpoint public và quản trị (prefix /api/admin/ với middleware riêng); áp dụng đặc quyền tối thiểu — mặc định từ chối, chỉ cho phép những gì khai báo rõ ràng.

Lỗi 6 — API6:2023: Truy cập luồng nghiệp vụ nhạy cảm không giới hạn

Đây là nhóm rủi ro mới được OWASP bổ sung trong bản 2023, nhắm vào các "luồng nghiệp vụ" nhạy cảm: mua hàng, đặt vé, chuyển tiền, đăng ký tài khoản, bình chọn... Những luồng này hợp lệ về mặt kỹ thuật — request đúng định dạng, user đã đăng nhập — nhưng bị lạm dụng với số lượng lớn để trục lợi.

Ví dụ minh họa: website bán vé giới hạn mỗi tài khoản mua 2 vé; attacker dùng script và tài khoản ảo gom hết vé rồi bán lại giá cao. Hoặc API áp mã giảm giá không giới hạn số lần dùng, attacker "cày" mã dùng một lần thành vô hạn. Theo OWASP, phần lớn mối đe dọa nhóm này giảm được bằng rate limiting hợp lý — nhưng nhiều hệ thống chưa triển khai.

Cách khắc phục: đặt giới hạn riêng cho từng luồng nhạy cảm (thanh toán, khuyến mãi, đăng ký) — theo ngày, theo tài khoản, theo thiết bị chứ không chỉ theo giây; thêm CAPTCHA ở bước nhạy cảm; ghi log để phát hiện bất thường (một tài khoản đặt 500 đơn/phút); xác thực số điện thoại thật khi cần.

Lỗi 7 — API7:2023: Giả mạo yêu cầu từ phía máy chủ (SSRF)

SSRF (Server-Side Request Forgery) xảy ra khi API cho phép user nhập một URL, rồi server tự động gửi request đến URL đó mà không kiểm tra. Kẻ tấn công lợi dụng để "mượn tay" server truy cập vào những địa chỉ mà từ bên ngoài không thể chạm tới — đặc biệt là mạng nội bộ và metadata của nhà cung cấp cloud.

Ví dụ minh họa: API "xem trước link" hoặc "tải ảnh từ URL" — attacker nhập http://169.254.169.254/latest/meta-data/, địa chỉ metadata nội bộ của nhiều nền tảng cloud chứa thông tin xác thực tạm thời của server. Nếu server không chặn, attacker đọc được credentials và chiếm quyền toàn bộ hạ tầng cloud.

Cách khắc phục: validate URL chặt chẽ — chỉ cho phép domain trong whitelist, chặn toàn bộ dải IP nội bộ (10.x, 172.16.x, 192.168.x, 169.254.x, localhost); hạn chế truy cập metadata service, dùng phiên bản yêu cầu xác thực (như IMDSv2 của AWS); server chạy API không nên "nhìn thấy" trực tiếp hệ thống nội bộ nhạy cảm.

Lỗi 8 — API8:2023: Cấu hình bảo mật sai và checklist kiểm tra định kỳ

Nhóm cuối cùng là "cấu hình sai" — nguyên nhân của rất nhiều vụ rò rỉ dữ liệu: để debug bật trên production, thiếu header bảo mật, CORS * kèm credentials, dùng HTTP thay vì HTTPS, quên tắt endpoint mặc định/test.

Ví dụ minh họa: team quên tắt trang debug trên production — khi API lỗi, server trả về câu lệnh SQL, đường dẫn file, thậm chí chuỗi kết nối database. Hoặc Swagger UI public kèm cả endpoint quản trị và token mẫu.

Cách khắc phục — checklist nên chạy định kỳ mỗi quý:

Ngoài 8 lỗi trên, OWASP API Security Top 10 2023 còn API9 — quản lý tồn kho API kém (phiên bản cũ không vá vẫn chạy) và API10 — tin tưởng mù quáng dữ liệu từ API bên thứ ba. Xem toàn văn tại trang giới thiệu dự án OWASP API Security.

Kết luận

Tám lỗi trên có điểm chung: phần lớn không phải lỗi "cao siêu" mà là lỗi quên — quên kiểm tra quyền, quên giới hạn, quên tắt debug. Bảo mật API tốt bắt đầu từ kỷ luật: kiểm tra phân quyền ở mọi endpoint, giới hạn tài nguyên, cấu hình đúng và rà soát định kỳ theo checklist OWASP. Hãy đưa 8 nhóm lỗi này vào quy trình review code và kiểm thử trước mỗi lần release.

Nếu hệ thống đang chạy trên hạ tầng thiếu lớp bảo vệ, rủi ro vẫn còn đó dù code có tốt đến đâu. SunCloud cung cấp Cloud Server và VPS tại datacenter chuẩn Tier III trong nước, kèm giải pháp an ninh — bảo mật hệ thống và hỗ trợ kỹ thuật 24/7. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn.

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

OWASP API Security Top 10 khác gì với OWASP Top 10 thông thường?

OWASP Top 10 truyền thống tập trung vào rủi ro ứng dụng web nói chung (injection, XSS...), còn OWASP API Security Top 10 chuyên sâu cho rủi ro đặc thù của API: phân quyền cấp đối tượng, tiêu thụ tài nguyên, luồng nghiệp vụ, SSRF... Hai tài liệu bổ sung cho nhau, nên tham khảo cả hai nếu hệ thống có app mobile hoặc microservices.

Có công cụ nào quét tự động các lỗi API này không?

Có các công cụ như OWASP ZAP, Burp Suite và giải pháp API security thương mại. Tuy nhiên công cụ tự động thường chỉ phát hiện lỗi kỹ thuật (thiếu header, cấu hình sai); lỗi logic như BOLA hay lạm dụng luồng nghiệp vụ vẫn cần kiểm thử thủ công bởi người hiểu nghiệp vụ hệ thống.

API chỉ dùng nội bộ có cần áp dụng OWASP Top 10 không?

Có. API nội bộ vẫn bị khai thác được nếu một thành phần trong mạng bị xâm nhập, và nhiều "API nội bộ" sau này được mở cho đối tác mà không rà soát lại. Áp dụng chuẩn bảo mật ngay từ đầu rẻ hơn nhiều so với vá sau sự cố.

Bao lâu nên rà soát bảo mật API một lần?

Tối thiểu mỗi quý rà checklist cấu hình, pentest chuyên sâu ít nhất mỗi năm một lần hoặc sau thay đổi kiến trúc lớn, thêm module thanh toán, mở API cho bên thứ ba. Endpoint thanh toán và dữ liệu cá nhân nên rà soát thường xuyên hơn.

Thuê pentest bên ngoài hay tự kiểm tra nội bộ thì tốt hơn?

Hai hình thức bổ sung cho nhau: team nội bộ hiểu nghiệp vụ nên phát hiện tốt lỗi logic (BOLA, luồng nghiệp vụ), đơn vị pentest độc lập mang góc nhìn kẻ tấn công và kinh nghiệm đa hệ thống. SME có thể bắt đầu bằng checklist OWASP nội bộ, rồi thuê pentest định kỳ cho hệ thống trọng yếu.

Ngoài code, hạ tầng máy chủ ảnh hưởng thế nào đến bảo mật API?

Rất nhiều. API chạy trên server không vá OS, không tường lửa, không giám sát log thì dù code tốt vẫn dễ bị chiếm quyền ở tầng hạ tầng (ví dụ SSRF đọc metadata cloud). Chọn nhà cung cấp có datacenter đạt chuẩn, hỗ trợ 24/7 và giải pháp bảo mật đi kèm sẽ giảm đáng kể rủi ro tầng này.