Bảo mật API là gì?

Mục lục

1. Bảo mật API là gì và khác gì bảo mật website thông thường?
2. Một yêu cầu API đi qua những lớp bảo vệ nào?
3. Xác thực và phân quyền API hoạt động thế nào?
4. OWASP API Security Top 10 là gì và có những rủi ro nào?
5. BOLA nguy hiểm ở điểm nào mà WAF khó phát hiện?
6. API bị lạm dụng, bị cạn tài nguyên: kiểm soát thế nào?
7. Làm sao biết doanh nghiệp đang có những API nào?
8. Bảo mật API cho doanh nghiệp Việt Nam: bắt đầu từ đâu?
9. Checklist bảo mật API để rà soát
10. Cách kiểm thử và giám sát bảo mật API
11. Bảo mật API khác gì với API gateway, WAF và zero trust?
12. Khi nào nên đầu tư sâu vào bảo mật API?
13. Những lỗi thường gặp khi bảo mật API
14. Câu hỏi thường gặp

Bảo mật API là gì và khác gì bảo mật website thông thường?

API (Application Programming Interface) là cổng để phần mềm này gọi chức năng hoặc lấy dữ liệu của phần mềm khác. Ứng dụng di động đặt hàng, cổng thanh toán trả kết quả giao dịch, hệ thống kế toán đồng bộ hoá đơn: tất cả đều đi qua API. Nếu bạn cần nền tảng về kiểu API phổ biến nhất, hãy đọc bài về RESTful API.

Theo cách Palo Alto Networks mô tả, bảo mật API là việc bảo vệ API khỏi các cuộc tấn công nhằm đánh cắp dữ liệu nhạy cảm hoặc làm gián đoạn dịch vụ, đồng thời bảo đảm chỉ người dùng được phép mới dùng được API và dữ liệu truyền qua không bị truy cập hay sửa đổi trái phép.

Điểm khác với bảo mật website truyền thống nằm ở ba chỗ:

• Không có giao diện làm “lá chắn”. Trên website, nút bấm chỉ cho người dùng làm vài thao tác. Với API, kẻ gọi có thể tự soạn yêu cầu, đổi tham số, gọi lặp hàng nghìn lần bằng script.
• Dữ liệu trả về thường thô. Máy chủ hay trả nguyên đối tượng (ví dụ cả hồ sơ khách hàng), còn ứng dụng phía người dùng mới là nơi ẩn bớt trường. Kẻ tấn công bỏ qua ứng dụng và đọc thẳng phản hồi.
• Lưu lượng đông–tây. Một yêu cầu từ ngoài có thể sinh hàng chục lời gọi API nội bộ giữa các dịch vụ. Kiến trúc microservices làm số lời gọi này tăng mạnh, nhưng tường lửa vành đai thường không nhìn thấy chúng.

Bảo mật API là một nhánh của an toàn thông tin, tập trung vào lớp ứng dụng thay vì mạng hay thiết bị đầu cuối.

Một yêu cầu API đi qua những lớp bảo vệ nào?

Hình dưới mô tả đường đi của một yêu cầu từ ứng dụng khách đến dữ liệu, và mỗi lớp kiểm tra điều gì. Không lớp nào thay được lớp khác.

Hai lớp đầu thường do hạ tầng đảm nhiệm. API gateway làm điểm vào duy nhất, kiểm tra token, áp hạn mức gọi và ghi nhật ký tập trung. WAF lọc các mẫu yêu cầu độc hại ở lớp HTTP. Hai lớp sau do lập trình viên viết, vì chỉ mã nghiệp vụ mới biết đơn hàng nào thuộc khách nào.

Xác thực và phân quyền API hoạt động thế nào?

Xác thực: bạn là ai

Mỗi cách xác thực phù hợp một ngữ cảnh khác nhau:

Cơ chế	Cách hoạt động	Phù hợp với	Điểm cần lưu ý
API key	Chuỗi bí mật gắn vào header của mỗi yêu cầu	Định danh ứng dụng gọi, tích hợp đơn giản giữa hệ thống	Không nói được ai là người dùng cuối. Lộ key trong mã nguồn hay kho Git là sự cố thường gặp
OAuth 2.0 / OpenID Connect	Máy chủ cấp quyền phát access token có phạm vi (scope) và hạn dùng	Ứng dụng di động, web, đối tác truy cập thay mặt người dùng	Phải cấu hình đúng luồng cấp quyền và kiểm tra scope ở phía API
JWT (JSON Web Token)	Token chứa các claim có chữ ký, API tự kiểm chữ ký, hạn và đối tượng nhận	Dịch vụ không lưu phiên (stateless)	Phải kiểm tra chữ ký, thời hạn (exp) và đối tượng nhận (aud). Khó thu hồi sớm nếu hạn dài
mTLS (TLS hai chiều)	Cả hai phía xuất trình chứng thư số	Giao tiếp giữa các dịch vụ nội bộ, kết nối B2B nhạy cảm	Tốn công cấp phát và gia hạn chứng thư

Với API có người dùng thật đăng nhập, nên kết hợp xác thực nhiều yếu tố ở bước cấp token. Phần này đã có bài riêng về xác thực đa yếu tố, ở đây chỉ cần nhớ: MFA bảo vệ lúc đăng nhập, còn token sau đó phải ngắn hạn để kẻ đánh cắp token không dùng được lâu.

Phân quyền: bạn được làm gì, với đối tượng nào

Phân quyền có ba mức, và lỗi thường xảy ra khi chỉ làm mức đầu:

• Mức chức năng: vai trò nhân viên bán hàng không được gọi API hoàn tiền hay xoá người dùng.
• Mức đối tượng: khách A gọi chi tiết đơn hàng thì chỉ thấy đơn của chính A, dù cùng được phép dùng chức năng “xem đơn”.
• Mức thuộc tính: khách được xem hồ sơ của mình nhưng không được thấy trường nội bộ như điểm rủi ro, và không được tự ghi vào trường như vai trò hay hạn mức.

Các mô hình phổ biến là RBAC (theo vai trò) và ABAC (theo thuộc tính của người dùng, đối tượng và ngữ cảnh). RBAC dễ hiểu, ABAC mềm dẻo hơn khi quy tắc phụ thuộc điều kiện như phòng ban hoặc giờ làm việc.

OWASP API Security Top 10 là gì và có những rủi ro nào?

OWASP là tổ chức phi lợi nhuận về an toàn ứng dụng. Danh sách API Security Top 10 đầu tiên công bố cuối năm 2019, bản cập nhật 2023 phát hành ngày 03/07/2023. Theo chính OWASP, phân quyền vẫn là thách thức lớn nhất: ba trong năm mục đầu liên quan kiểm soát truy cập. Bản 2023 thêm ba mục mới là truy cập không hạn chế vào luồng nghiệp vụ nhạy cảm, SSRF và tiêu thụ API không an toàn.

Mã	Rủi ro	Hiểu nôm na	Hướng phòng chống chính
API1	Broken Object Level Authorization (BOLA)	Đổi mã đối tượng trong yêu cầu là xem được dữ liệu người khác	Kiểm tra quyền sở hữu ở mỗi endpoint nhận mã đối tượng
API2	Broken Authentication	Token yếu, đăng nhập không chống đoán mật khẩu	Token ngắn hạn, MFA, khoá hoặc làm chậm khi thử sai nhiều lần
API3	Broken Object Property Level Authorization	Đọc hoặc ghi trường không được phép (gộp lộ dữ liệu thừa và mass assignment của bản 2019)	Lọc trường trả về theo vai trò, danh sách trường được phép ghi
API4	Unrestricted Resource Consumption	Gọi quá nhiều hoặc quá nặng làm cạn tài nguyên, đội chi phí	Giới hạn tốc độ, kích thước, độ sâu truy vấn, thời gian xử lý
API5	Broken Function Level Authorization	Người thường gọi được chức năng quản trị	Mặc định từ chối, tách rõ route quản trị
API6	Unrestricted Access to Sensitive Business Flows	Bot lạm dụng luồng hợp lệ như tạo tài khoản hàng loạt, gom hàng khuyến mãi	Xác định luồng nhạy cảm, nhận diện bot, giới hạn theo thiết bị hoặc tài khoản
API7	Server Side Request Forgery	API bị lừa gọi tới địa chỉ nội bộ do kẻ tấn công chỉ định	Danh sách địa chỉ đích cho phép, chặn dải mạng nội bộ
API8	Security Misconfiguration	Bật chế độ debug, CORS quá rộng, thiếu header bảo mật	Cấu hình chuẩn hoá, rà soát tự động
API9	Improper Inventory Management	Không biết mình đang có API nào, phiên bản cũ vẫn chạy	Danh mục API, tắt phiên bản cũ
API10	Unsafe Consumption of APIs	Tin dữ liệu từ API bên thứ ba mà không kiểm tra	Kiểm tra và giới hạn dữ liệu nhận từ đối tác như dữ liệu người dùng

Lưu ý rằng các lỗi tiêm mã như SQL injection không còn là một mục riêng trong bản 2023 như mục Injection của bản 2019. Tuy vậy, chúng vẫn tồn tại và đã được dồn vào nhóm tiêu thụ API không an toàn và việc kiểm tra đầu vào nói chung.

BOLA nguy hiểm ở điểm nào mà WAF khó phát hiện?

BOLA đứng đầu danh sách từ 2019 và vẫn giữ vị trí này năm 2023. Ví dụ minh hoạ: ứng dụng bán hàng có endpoint xem chi tiết đơn theo mã. Khách A đăng nhập hợp lệ, xem đơn mã 1001 của mình. Nếu API chỉ kiểm tra “đã đăng nhập” mà không kiểm tra đơn 1001 có thuộc A hay không, A đổi mã sang số khác sẽ xem được đơn của người khác.

WAF khó bắt lỗi này vì yêu cầu trông hoàn toàn bình thường: token hợp lệ, cú pháp đúng, không có chuỗi độc hại. Chỉ mã nghiệp vụ mới biết đơn nào của ai. Cách phòng chống bền vững là đặt kiểm tra quyền sở hữu ngay tầng truy vấn dữ liệu (ví dụ luôn truy vấn kèm điều kiện mã khách hàng lấy từ token, không lấy từ tham số do người gọi gửi lên). Nên dùng mã đối tượng khó đoán như UUID, nhưng đó chỉ là lớp phụ, không thay cho kiểm tra quyền.

API bị lạm dụng, bị cạn tài nguyên: kiểm soát thế nào?

Không phải mọi cuộc tấn công đều đánh cắp dữ liệu. Có loại chỉ cần gọi nhiều. Mục API4 của OWASP mô tả API không đặt giới hạn tiêu thụ tài nguyên, dẫn đến chậm, sập hoặc đội chi phí vận hành, nhất là khi API gắn với dịch vụ tính phí theo lượt như gửi SMS hoặc email. Mục API6 nói về lạm dụng các luồng nhạy cảm như tạo tài khoản giả hoặc gom hàng khuyến mãi bằng bot.

Các kiểm soát cụ thể thường dùng:

• Giới hạn tốc độ (rate limiting): đặt theo token hoặc khách hàng, không chỉ theo địa chỉ IP, vì nhiều người dùng chung một IP công ty còn bot có thể đổi IP. Khi vượt hạn mức, trả mã HTTP 429.
• Giới hạn kích thước và phân trang: đặt trần số bản ghi mỗi lần gọi, kích thước nội dung gửi lên, thời gian xử lý tối đa. Với GraphQL cần thêm giới hạn độ sâu và độ phức tạp truy vấn.
• Hạn mức riêng cho thao tác tốn tiền: gửi mã OTP, gửi email, gọi dịch vụ bên thứ ba cần trần theo ngày cho mỗi số điện thoại hoặc tài khoản. Với luồng OTP có thể tham khảo bài về mã OTP.
• Chống tự động hoá cho luồng nhạy cảm: thử thách người thật, nhận diện thiết bị, hoặc yêu cầu bước xác minh thêm khi hành vi bất thường.

Đối với tấn công làm nghẽn quy mô lớn, giới hạn ở tầng API là chưa đủ, cần phòng thủ ở tầng mạng. Phần đó nằm trong bài về DDoS.

Làm sao biết doanh nghiệp đang có những API nào?

Mục API9 (Improper Inventory Management) thường bị coi nhẹ nhất. Thực tế hay gặp:

• Shadow API: đội phát triển tạo endpoint thử nghiệm hay endpoint cho đối tác rồi không đăng ký với ai.
• Zombie API: phiên bản cũ như v1 vẫn chạy sau khi đã ra v3, và vẫn thiếu các bản vá mới.
• Môi trường thử nghiệm mở ra Internet, chứa dữ liệu thật sao chép về để test.

Cách làm là lập danh mục API gồm: tên, chủ sở hữu, phiên bản, môi trường, loại dữ liệu xử lý, ai được gọi, ngày dự kiến ngừng. Nguồn để đối chiếu gồm tệp mô tả OpenAPI trong kho mã, cấu hình gateway, nhật ký truy cập của máy chủ web và bản ghi DNS (các tên miền con kiểu api, dev, staging). Nếu API xuất hiện trong nhật ký mà không có trong danh mục, đó là API chưa quản lý.

Bảo mật API cho doanh nghiệp Việt Nam: bắt đầu từ đâu?

Các hệ thống phổ biến ở doanh nghiệp Việt như ứng dụng giao hàng, cổng đại lý, tích hợp hoá đơn điện tử, ví điện tử, kết nối ERP với website bán hàng đều chạy trên API. Nhiều doanh nghiệp vừa và nhỏ không tự viết API mà dùng của nhà cung cấp. Khi đó rủi ro chuyển sang quản lý khoá và quyền: ai giữ API key của phần mềm kế toán, key có nằm trong tệp cấu hình chia sẻ qua chat hay không, nhân viên nghỉ việc có bị thu hồi quyền không.

Nếu API trả hoặc nhận dữ liệu cá nhân như họ tên, số điện thoại, số căn cước, địa chỉ, thì phản hồi cần chỉ chứa trường thật sự cần dùng, và nhật ký truy cập không được ghi nguyên văn các trường đó. Khái niệm và nghĩa vụ chung nằm ở bài về bảo vệ dữ liệu cá nhân.

Checklist bảo mật API để rà soát

Nhóm	Câu hỏi kiểm tra	Dấu hiệu đạt
Đường truyền	Mọi endpoint có chỉ chấp nhận HTTPS?	Yêu cầu HTTP thường bị từ chối hoặc chuyển hướng, dùng TLS phiên bản hiện hành
Xác thực	Token có hạn ngắn và kiểm tra đủ chữ ký, hạn, đối tượng nhận?	Token hết hạn bị từ chối, token cấp cho dịch vụ khác không dùng được
Phân quyền	Mỗi endpoint nhận mã đối tượng có kiểm tra chủ sở hữu?	Có bài kiểm thử tự động dùng hai tài khoản để chéo dữ liệu và kết quả là bị từ chối
Dữ liệu trả về	Phản hồi có lọc trường theo vai trò?	Không trả hàm băm mật khẩu, mã nội bộ, trường không giao diện nào dùng
Dữ liệu nhận vào	Có kiểm tra theo lược đồ (kiểu, độ dài, giá trị cho phép)?	Trường lạ bị bỏ qua hoặc bị từ chối, trường vai trò không ghi được từ phía khách
Giới hạn	Có hạn mức theo token, kích thước, phân trang?	Gọi dồn dập nhận mã 429, không có API trả cả bảng dữ liệu
Bí mật	Khoá và chuỗi kết nối có nằm ngoài mã nguồn?	Dùng kho quản lý bí mật, có quy trình xoay vòng và thu hồi khi nhân sự thay đổi
Kiểm kê	Có danh mục API và kế hoạch ngừng bản cũ?	Mọi API xuất hiện trong nhật ký đều có chủ sở hữu
Giám sát	Nhật ký có ghi người gọi, endpoint, mã phản hồi và có cảnh báo?	Có cảnh báo khi một token đọc hàng loạt đối tượng khác nhau, hoặc tăng đột ngột mã 401, 403

Cách kiểm thử và giám sát bảo mật API

Có bốn cách bổ trợ nhau. Kiểm thử tĩnh (SAST) và quét thư viện phụ thuộc chạy ngay khi lập trình viên nộp mã. Kiểm thử động (DAST) gọi thử API đang chạy ở môi trường thử nghiệm dựa trên tệp OpenAPI để tìm cấu hình sai. Kiểm thử logic phân quyền cần kịch bản riêng, vì công cụ tự động không biết quy tắc nghiệp vụ của bạn: dùng hai tài khoản khác vai trò và kiểm tra chéo từng endpoint. Với hệ thống quan trọng, đưa API vào phạm vi của kiểm thử xâm nhập do bên độc lập thực hiện.

Về giám sát, nhật ký gateway cần chuyển về nơi tập trung để phân tích. Những tín hiệu có giá trị riêng cho API gồm: một token truy cập tuần tự nhiều mã đối tượng, tỷ lệ lỗi 401 và 403 tăng đột ngột, lượng dữ liệu trả về bất thường của một khách hàng, và các lời gọi từ vị trí địa lý không điển hình. Nền tảng SIEM có thể làm nơi gom và tạo cảnh báo, nhưng hiệu quả phụ thuộc vào việc nhật ký ghi đúng các trường nêu trên.

Bảo mật API khác gì với API gateway, WAF và zero trust?

Khái niệm	Bản chất	Quan hệ với bảo mật API
Bảo mật API	Mục tiêu và tập hợp biện pháp	Là cái đích, gồm cả thiết kế, mã nguồn, vận hành
API gateway	Thành phần hạ tầng làm điểm vào	Thực thi xác thực, hạn mức, định tuyến. Không biết quy tắc sở hữu dữ liệu
WAF	Bộ lọc yêu cầu HTTP theo mẫu	Chặn mẫu tấn công đã biết, khó bắt lỗi logic như BOLA
Zero trust	Mô hình kiến trúc không mặc định tin ai	API nội bộ cũng phải xác thực và phân quyền. Xem bài zero trust

Khi nào nên đầu tư sâu vào bảo mật API?

Hai tình huống khác nhau cần cách tiếp cận khác nhau, thể hiện ở ma trận dưới đây.

Ô góc trên bên phải là nơi gồm API thanh toán, API mở cho đối tác, API chứa hồ sơ khách hàng. Ở đó nên có gateway, WAF, phân quyền theo thuộc tính, giám sát hành vi và kiểm thử độc lập định kỳ. Ô góc dưới bên trái, như API nội bộ chỉ trả dữ liệu công khai, vẫn cần HTTPS, xác thực và nhật ký, nhưng không cần dựng cả bộ công cụ chuyên dụng.

Những lỗi thường gặp khi bảo mật API

• Chỉ dựa vào ẩn giao diện. Ẩn nút trên ứng dụng không chặn được ai gọi thẳng API. Mọi quy tắc phải được kiểm tra phía máy chủ.
• Tin vào mã đối tượng hoặc mã người dùng trong nội dung yêu cầu. Định danh người gọi phải lấy từ token đã xác minh, không lấy từ tham số do người gọi gửi.
• Trả nguyên bản ghi. Việc “trả hết, ứng dụng tự ẩn” dẫn đến lộ trường dữ liệu thừa. Hãy định nghĩa riêng cấu trúc phản hồi cho từng vai trò.
• Cho phép cập nhật hàng loạt theo cấu trúc đối tượng. Nếu API tự gán mọi trường khách gửi lên vào bản ghi, khách có thể ghi cả trường như vai trò hoặc hạn mức (mass assignment). Dùng danh sách trường được phép ghi.
• Đưa khoá vào mã nguồn hoặc ứng dụng di động. Bất kỳ bí mật nào nằm trong ứng dụng phát hành đều có thể bị trích xuất. Khoá cần giữ ở máy chủ.
• Thông báo lỗi quá chi tiết. Trả nguyên dấu vết ngăn xếp hay câu truy vấn lỗi tiết lộ cấu trúc hệ thống.
• Tin tuyệt đối vào API đối tác. Dữ liệu từ bên thứ ba cũng phải được kiểm tra, giới hạn kích thước và không được dùng để dựng truy vấn hay địa chỉ gọi tiếp mà không lọc.

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

Bảo mật API có giống bảo mật ứng dụng web không?

Có phần chung nhưng không giống. Cả hai cùng nằm ở lớp ứng dụng, nhưng API không có giao diện ngăn người dùng thao tác ngoài ý muốn, trả dữ liệu thô và phục vụ cả giao tiếp giữa máy với máy. Vì vậy trọng tâm dịch sang phân quyền theo đối tượng, giới hạn tốc độ và kiểm kê endpoint.

Chỉ cần mua WAF là đủ bảo mật API?

Không. WAF chặn tốt các mẫu yêu cầu độc hại đã biết, nhưng không biết đơn hàng nào thuộc khách nào nên khó phát hiện lỗi như BOLA. WAF nên đi cùng phân quyền trong mã nguồn, giới hạn tốc độ, kiểm kê API và giám sát nhật ký.

API key và OAuth 2.0 khác nhau thế nào?

API key chủ yếu định danh ứng dụng gọi và thường không có phạm vi quyền chi tiết hay hạn dùng ngắn. OAuth 2.0 cấp access token có phạm vi và thời hạn, cho phép ứng dụng hành động thay mặt một người dùng cụ thể mà không cần biết mật khẩu của họ. Khi API xử lý dữ liệu theo từng người dùng, OAuth 2.0 là lựa chọn thích hợp hơn.

OWASP API Security Top 10 có bắt buộc áp dụng không?

Không. Đây là tài liệu tham chiếu do cộng đồng OWASP xây dựng, không phải văn bản pháp luật hay tiêu chuẩn bắt buộc. Nhiều đội dùng nó làm khung để rà soát thiết kế, viết kịch bản kiểm thử và đặt yêu cầu bảo mật khi đấu thầu hay nghiệm thu phần mềm.

Làm sao biết API của mình đã bị lạm dụng?

Tìm các dấu hiệu trong nhật ký: một token đọc tuần tự rất nhiều mã đối tượng khác nhau, tỷ lệ mã 401 hoặc 403 tăng đột ngột, lượng dữ liệu trả về của một khách vượt xa mức thông thường, hoặc chi phí dịch vụ tính theo lượt tăng bất thường. Muốn thấy được các dấu hiệu này, nhật ký phải ghi định danh người gọi, endpoint và mã phản hồi.

API nội bộ không ra Internet có cần bảo mật không?

Có. Kẻ đã xâm nhập một máy trong mạng nội bộ có thể gọi các API nội bộ, và nhiều sự cố đến từ chính thông tin xác thực bị đánh cắp. Vì vậy dịch vụ nội bộ cũng nên xác thực lẫn nhau, ví dụ bằng mTLS hoặc token cấp cho từng dịch vụ, và phân quyền theo nhu cầu thực tế.