BOLA là gì? Hướng dẫn phát hiện & Fix lỗi API chuẩn OWASP

Broken Object Level Authorization (BOLA) là lỗ hổng bảo mật API nghiêm trọng nhất hiện nay, xảy ra khi hệ thống không xác minh quyền sở hữu của người dùng đối với một ID dữ liệu cụ thể. Lỗi này cho phép người dùng bình thường dễ dàng thao túng các tham số định danh để đánh cắp, chỉnh sửa hoặc xóa dữ liệu của người khác mà không cần quyền quản trị. Cùng VinaHost khám phá chi tiết hơn về BOLA qua bài viết sau.

1. Broken Object Level Authorization (BOLA) là gì?

Broken Object Level Authorization (BOLA) là lỗ hổng kiểm soát truy cập API xảy ra khi hệ thống không xác minh quyền sở hữu của người dùng đối với một ID đối tượng cụ thể. Lỗi này cho phép người dùng đã đăng nhập dễ dàng thao túng ID trên URL hoặc payload để xem, sửa, hoặc xóa dữ liệu của người khác mà không cần quyền quản trị.

Rủi ro bảo mật này thường xảy ra khi:

• API không thực hiện kiểm tra quyền truy cập đúng cho các tài nguyên dựa trên “object ID” (tức các định danh đối tượng như ID, UUID,…); và
• Người dùng (đã xác thực – authenticated) có thể thao túng ID đối tượng trong yêu cầu API để truy cập, xem, chỉnh sửa hoặc xóa dữ liệu mà họ không được phép.

Nói cách khác, hệ thống API có thể xác thực ai đang gửi yêu cầu, nhưng không kiểm tra xem người đó có quyền truy cập đúng vào tài nguyên đó hay không. Đây chính là kẽ hở chí mạng giúp kẻ gian dễ dàng đánh cắp dữ liệu dù không có tài khoản quản trị.

2. 4 Nguyên nhân gốc rễ khiến BOLA trở nên phổ biến

Bốn nguyên nhân chính khiến lỗ hổng BOLA xuất hiện trong các cuộc tấn công API bao gồm: quá tin tưởng vào ID do phía client gửi lên; sử dụng ID tuần tự dễ đoán (1, 2, 3…) từ phía client, thiếu bước xác minh quyền sở hữu ở logic server và áp lực phát hành phần mềm nhanh khiến khâu kiểm thử phân quyền bị bỏ qua.

2.1. Quá tin tưởng vào ID từ Client

• Nguyên nhân: Nhiều API dựa vào các ID đối tượng (object IDs) do phía client gửi lên để xác định tài nguyên cần truy cập, nhưng không xác thực quyền sở hữu trước khi trả dữ liệu hoặc cho phép thao tác. Do ID thường được gửi từ client nên có thể bị chỉnh sửa/tampering dễ dàng.
• Hệ quả: Kẻ tấn công chỉ cần thay đổi ID (ví dụ từ /users/123 sang /users/124) là có thể truy xuất tài nguyên không thuộc quyền mình nếu API không kiểm tra lại quyền đối với tài nguyên đó. Từ đó, hàng loạt dữ liệu nhạy cảm của người dùng khác có thể bị lộ lọt một cách dễ dàng.

2.2. Thiếu cơ chế xác minh quyền sở hữu

• Nguyên nhân: API có thể xác thực người dùng (authentication) nhưng lại bỏ qua bước kiểm tra quyền sở hữu đối tượng cụ thể mà người dùng yêu cầu (authorization). Lỗi này thường xuất phát từ việc lập trình viên lầm tưởng rằng chỉ cần đăng nhập thành công là người dùng mặc định được phép thao tác.
• Hệ quả: Kẻ tấn công giả danh người dùng hợp lệ, gửi yêu cầu với ID tài nguyên của người khác mà hệ thống API vẫn đáp ứng. Điều này xảy ra do API chỉ kiểm tra họ đã đăng nhập hay chưa, chứ không hề xác minh xem họ có quyền hạn với chính tài nguyên đang bị nhắm tới hay không.

2.3. Sử dụng ID tuần tự hoặc dễ đoán

• Nguyên nhân: Nhiều hệ thống sử dụng ID tuần tự (1, 2, 3, …) cho các đối tượng (user, order, invoice…) hoặc ID có thể dự đoán bằng cách đếm tăng dần. Việc thiết kế cấu trúc ID như vậy tạo điều kiện vô cùng thuận lợi cho các chiến dịch rà quét tự động của hacker.
• Hệ quả: Kẻ tấn công có thể dễ dàng “enumerate” (duyệt thử) các ID để truy cập vào tài nguyên khác nếu API không thực hiện kiểm tra quyền đầy đủ. Chúng chỉ cần viết một đoạn mã script đơn giản để tự động thay đổi ID liên tục và thu thập toàn bộ cơ sở dữ liệu.

2.4. Văn hóa “Speed over Security”

• Nguyên nhân: Trong nhiều tổ chức phát triển phần mềm, áp lực release nhanh và tối ưu thời gian phát triển dẫn tới yếu tố bảo mật bị đặt ở mức thấp hơn trong chu trình xây dựng API. Đặc biệt, khâu thiết kế logic phân quyền chi tiết thường bị bỏ qua hoặc làm một cách sơ sài.
• Hệ quả: Việc thiếu quy trình đánh giá, kiểm tra phân quyền ở mọi endpoint API khiến nhiều sai sót về quyền truy cập bị bỏ lọt cho đến khi sản phẩm vận hành. Khi các lỗ hổng này được phát hiện, hệ thống có thể đã phải gánh chịu những thiệt hại nặng nề về mặt dữ liệu.

3. Cơ chế tấn công của BOLA: Hacker thao túng API như thế nào?

Hacker thao túng API mắc lỗi BOLA thông qua 4 bước cơ bản: chặn bắt request bằng công cụ (như Burp Suite), nhận diện tham số ID đối tượng (ví dụ /users/123), đổi giá trị ID đó sang ID của nạn nhân (thành /users/124) và gửi yêu cầu để chiếm đoạt dữ liệu. Kỹ thuật này không cần mã độc mà đánh thẳng vào lỗ hổng logic phân quyền ở máy chủ.

3.1. Bước 1: Trinh sát

Kẻ tấn công thường bắt đầu bằng việc quan sát tỉ mỉ cách ứng dụng giao tiếp với API. Quá trình trinh sát này giúp chúng tìm ra những điểm yếu logic trong hệ thống trước khi ra đòn quyết định.

• Chúng có thể sử dụng các công cụ kiểm thử bảo mật như Burp Suite để chặn (intercept) và phân tích request.
• Mục tiêu là xác định các API endpoint có chứa tham số định danh đối tượng (ví dụ: userId, orderId, invoiceId…).
• Từ đó, chúng nhận diện được những điểm mà hệ thống đang dựa vào ID do client gửi lên.

3.2. Bước 2: Thao túng

Sau khi xác định được các endpoint có chứa tham số ID, hacker sẽ bắt đầu can thiệp vào các gói tin. Chúng tiến hành các bước thao túng tiếp theo để xem phản ứng của server.

• Kẻ tấn công thay đổi giá trị ID trong:
  • URL (ví dụ: /api/users/123 → /api/users/124)
  • Header
  • Hoặc trong Body (JSON) của request
• Mục tiêu là kiểm tra xem server có thực sự xác minh quyền truy cập đối với ID mới đó hay không. Nếu server chấp nhận yêu cầu, hacker sẽ biết chắc chắn hệ thống này dính lỗi BOLA.

3.3. Bước 3: Truy cập trái phép

Nếu API tồn tại lỗ hổng BOLA, quá trình khai thác sẽ lập tức chuyển sang giai đoạn truy xuất dữ liệu. Kẻ tấn công lúc này đã hoàn toàn vượt qua được rào cản phân quyền của hệ thống.

• Server vẫn trả về dữ liệu dù người gửi request không hề có quyền hạn với đối tượng đó. Lỗ hổng này biến các cơ chế xác thực đăng nhập ban đầu trở nên hoàn toàn vô nghĩa.
• Dữ liệu bị rò rỉ có thể bao gồm: hồ sơ cá nhân, tin nhắn riêng tư, hình ảnh hoặc thông tin đơn hàng. Thậm chí, những dữ liệu tài chính nhạy cảm của tổ chức cũng có nguy cơ bị phơi bày.

Đây là điểm mấu chốt của BOLA: hệ thống chỉ xác thực người dùng nhưng lại không kiểm tra quyền trên từng đối tượng cụ thể. Sai lầm tai hại này biến một người dùng bình thường thành kẻ có đặc quyền truy cập mọi nơi.

3.4. Bước 4: Leo thang ảnh hưởng

Trong nhiều trường hợp, hậu quả của BOLA không chỉ dừng lại ở việc đọc trộm dữ liệu. Kẻ tấn công còn có thể can thiệp sâu hơn vào các hoạt động cốt lõi của hệ thống.

• Nếu API cho phép các phương thức như PUT, PATCH, DELETE,
• Và vẫn thiếu kiểm tra quyền ở cấp object,

thì kẻ tấn công có thể:

• Chỉnh sửa (Edit) dữ liệu của người khác
• Xóa (Delete) tài nguyên
• Hoặc thay đổi trạng thái hệ thống

Điều này làm mức độ rủi ro tăng vọt từ rò rỉ dữ liệu đơn thuần sang xâm phạm tính toàn vẹn của dữ liệu. Hậu quả là doanh nghiệp không chỉ mất mát thông tin mà còn đối mặt với nguy cơ hệ thống bị phá hoại hoàn toàn.

4. BOLA và IDOR có giống nhau hay không?

BOLA và IDOR về bản chất kỹ thuật là hoàn toàn giống nhau, đều chỉ chung một nhóm lỗi phân quyền ở cấp độ đối tượng. Sự khác biệt chỉ nằm ở ngữ cảnh: IDOR là thuật ngữ cũ hơn (xuất hiện trong OWASP Top 10 cho ứng dụng web từ 2007), mô tả việc ứng dụng phơi bày tham chiếu trực tiếp đến tài nguyên nội bộ (file, bản ghi CSDL, khóa chính…), trong khi BOLA là thuật ngữ được OWASP sử dụng từ năm 2019 để nhấn mạnh vào lỗi uỷ quyền (Authorization) trong kiến trúc API hiện đại.

• Trước đây, IDOR là thuật ngữ quen thuộc thường xuất hiện trong danh sách OWASP Top 10 dành cho các ứng dụng web truyền thống. Thuật ngữ này tập trung nhiều vào bề mặt tham chiếu trực tiếp đến các tệp tin hoặc thư mục.
• Đến khi xây dựng danh sách chuyên biệt cho API trong OWASP API Security Project, tổ chức này đã chuyển sang sử dụng thuật ngữ BOLA. Mục đích của sự thay đổi này là để nhấn mạnh yếu tố Authorization (ủy quyền) thay vì chỉ tập trung vào việc tham chiếu ID trực tiếp như trước.

Điểm giống nhau

• Cả hai lỗ hổng đều xảy ra khi hệ thống không kiểm tra quyền truy cập đối với từng object ID cụ thể.
• Cả hai đều cho phép người dùng đã xác thực truy cập tài nguyên không thuộc quyền của mình bằng cách thay đổi ID.

Điểm khác biệt về cách gọi

• IDOR nhấn mạnh vào hành vi tham chiếu trực tiếp đến tài nguyên (ví dụ: /users/123).
• BOLA nhấn mạnh vào lỗi trong cơ chế phân quyền ở cấp đối tượng, đặc biệt trong kiến trúc API hiện đại (REST, GraphQL, mobile backend…).

Tóm lại, có thể hiểu rằng BOLA là cách OWASP định danh lại lỗ hổng IDOR trong bối cảnh kiến trúc API hiện đại. Sự thay đổi tên gọi này nhằm phản ánh rõ bản chất cốt lõi của vấn đề là lỗi kiểm soát ủy quyền, chứ không chỉ đơn thuần là việc tham chiếu ID trực tiếp.

5. Các ví dụ thực tế và Kịch bản tấn công tại Việt Nam

Lỗ hổng BOLA thường gây ra hậu quả rò rỉ dữ liệu nghiêm trọng nhất trong 4 lĩnh vực: Y tế (lộ bệnh án), Tài chính/Fintech (thao túng hóa đơn, giao dịch), kiến trúc GraphQL (xóa/sửa tệp tin trái phép), và Mạng xã hội (lộ thông tin cá nhân PII).

Dưới đây là các kịch bản minh họa mang tính phân tích rủi ro bảo mật. Nội dung nhằm mục đích nâng cao nhận thức về an toàn API, không cổ vũ hay hướng dẫn hành vi xâm nhập trái phép.

5.1. Lĩnh vực y tế

Kịch bản: Truy cập hồ sơ bệnh án trái phép

Mô tả:
Một ứng dụng đặt lịch khám sử dụng ID tuần tự cho hồ sơ bệnh nhân (ví dụ: patient_id=1001, 1002, 1003…). Nếu API không kiểm tra quyền truy cập ở cấp đối tượng, kẻ tấn công có thể thay đổi ID để xem:

• Lịch sử khám bệnh
• Đơn thuốc
• Kết quả xét nghiệm
• Thông tin cá nhân nhạy cảm

Rủi ro pháp lý:

• Vi phạm nghiêm trọng quyền riêng tư cá nhân
• Có thể vi phạm các quy định của Luật Khám bệnh, chữa bệnh
• Có nguy cơ vi phạm Luật An ninh mạng nếu dẫn đến rò rỉ dữ liệu diện rộng

5.2. Lĩnh vực Tài chính/Fintech

Kịch bản: Thao túng hóa đơn tài chính & ví điện tử

Mô tả:

Các hệ thống thanh toán điện tử thường sử dụng các mã định danh như invoice_id hoặc transaction_id cho từng giao dịch. Nếu hệ thống này không kiểm tra chặt chẽ quyền sở hữu đối tượng đối với từng phiên làm việc:

• Kẻ tấn công có thể thay đổi invoice_id
• Tải xuống hóa đơn VAT của doanh nghiệp khác
• Xem thông tin giao dịch, giá trị hợp đồng, mã số thuế

Hậu quả tiềm ẩn:

• Rò rỉ thông tin tài chính nhạy cảm
• Ảnh hưởng bí mật kinh doanh
• Rủi ro gian lận hoặc giả mạo giao dịch

5.3. Xóa tệp tin qua GraphQL

Kịch bản: Xóa dữ liệu qua tham số GraphQL

Mô tả:

Kiến trúc GraphQL mang lại sự linh hoạt cao nhưng cũng tiềm ẩn nhiều rủi ro nếu phân quyền không tốt. Ví dụ, trong một hệ thống sử dụng GraphQL, nếu mutation cho phép các thao tác như:

• deleteFile(fileId: “123”)

mà không xác minh quyền đối với fileId, thì kẻ tấn công có thể:

• Thay đổi fileId
• Xóa tệp tin của người dùng khác
• Làm mất dữ liệu quan trọng

Trong môi trường API hiện đại (microservices, mobile backend), lỗi BOLA trong GraphQL thường bị ẩn giấu rất sâu. Lỗ hổng này rất khó bị phát hiện nếu đội ngũ phát triển không tiến hành kiểm thử phân quyền đầy đủ cho từng bộ giải quyết (resolver) riêng biệt.

5.4. Mạng xã hội và Ứng dụng Chat

Kịch bản: Rò rỉ hồ sơ cá nhân (PII) qua User ID

Mô tả:

Chức năng xem hồ sơ cá nhân là tính năng cơ bản của hầu hết các ứng dụng hiện nay. Tuy nhiên, nếu API trả về thông tin hồ sơ dựa trên user_id mà không kiểm tra quyền truy cập chi tiết, kẻ tấn công có thể dễ dàng thay đổi ID để thu thập:

• Số điện thoại
• Email
• Địa chỉ nhà riêng
• Thông tin cá nhân khác (PII – Personally Identifiable Information)

Rủi ro:

• Xâm phạm quyền riêng tư
• Lừa đảo (phishing, social engineering)
• Tấn công nhắm mục tiêu

6. Chiến lược phòng chống BOLA toàn diện năm 2026

Chiến lược hiệu quả nhất để phòng chống lỗ hổng BOLA triệt để là áp dụng mô hình Zero Trust: bắt buộc kiểm tra quyền sở hữu trên TỪNG yêu cầu API ở tầng business logic, kết hợp với việc thay thế ID tự tăng bằng chuỗi ngẫu nhiên (UUID) và triển khai hệ thống bảo vệ WAAP để chặn đứng các hành vi dò quét tự động.

6.1. Nguyên tắc 1: Kiểm tra quyền hạn trên TỪNG yêu cầu (Zero Trust)

• Tổ chức cần áp dụng mô hình bảo mật Zero Trust (Không tin tưởng tuyệt đối). Điều này có nghĩa là hệ thống tuyệt đối không tin tưởng bất kỳ yêu cầu nào chỉ vì người dùng đó đã đăng nhập thành công.
• Mỗi request phải được:
  • Xác thực danh tính (Authentication)
  • Kiểm tra quyền trên từng object cụ thể (Authorization at object level)
• Việc kiểm tra phân quyền cần phải được thực hiện sâu ở tầng business logic của ứng dụng. Lập trình viên không nên chỉ phụ thuộc vào các lớp middleware kiểm tra quyền hạn chung chung bên ngoài.

Mục tiêu của phương pháp này là đảm bảo mọi truy cập ở cấp độ đối tượng đều được hệ thống đánh giá lại từ đầu. Nó giúp loại bỏ hoàn toàn sự ỷ lại vào trạng thái phiên đăng nhập đã được thiết lập trước đó.

6.2. Nguyên tắc 2: Sử dụng ID ngẫu nhiên (UUID/GUID)

Nguyên tắc quan trọng tiếp theo là tuyệt đối tránh sử dụng các ID dạng tuần tự (1, 2, 3…) cho cơ sở dữ liệu. Cấu trúc ID này quá dễ đoán và sẽ tạo điều kiện cho hacker rà quét hàng loạt.

Thay vào đó, tổ chức nên ưu tiên sử dụng UUID/GUID hoặc các chuỗi định danh ngẫu nhiên khó đoán. Biện pháp này sẽ giúp giảm thiểu đáng kể nguy cơ bị dò quét (enumeration) dữ liệu trái phép.

6.3. Nguyên tắc 3: Áp dụng API Gateway và Rate Limiting

Triển khai API Gateway là một bước đệm để tăng cường khả năng phòng thủ. Hệ thống này đóng vai trò như một chốt chặn kiểm soát, giúp:

• Kiểm soát tập trung truy cập API
• Áp dụng chính sách xác thực & phân quyền thống nhất
• Giới hạn tốc độ (Rate Limiting) để phát hiện hành vi quét ID bất thường

Cần lưu ý rằng Rate Limiting không thể thay thế hoàn toàn cho việc kiểm tra phân quyền cốt lõi. Tuy nhiên, nó vẫn là một lớp khiên đắc lực giúp phát hiện và giảm thiểu các hành vi khai thác tự động từ mạng lưới botnet.

6.4. Nguyên tắc 4: Xác định đầu vào và Làm sạch dữ liệu

Hãy luôn thực hiện xác thực dữ liệu đầu vào trước khi xử lý bất kỳ request nào. Đây là chốt chặn cơ bản nhất để loại bỏ các đoạn mã hoặc định dạng độc hại thông qua việc:

• Kiểm tra định dạng ID
• Từ chối các giá trị bất thường hoặc sai cấu trúc

Việc kiểm soát đầu vào chặt chẽ sẽ giúp thu hẹp đáng kể bề mặt tấn công của toàn bộ hệ thống API. Đồng thời, nó hạn chế triệt để việc kẻ gian cố tình thao túng các tham số trái phép để vượt quyền.

6.5. Nguyên tắc 5: Triển khai các lớp bảo vệ tự động với WAAP

Ngoài việc kiểm soát logic ở tầng ứng dụng, các doanh nghiệp cũng cần trang bị thêm các giải pháp an ninh mạng vòng ngoài. Cụ thể, việc triển khai lớp bảo vệ chuyên biệt như WAAP (Web Application & API Protection) là vô cùng cần thiết trong bối cảnh hiện nay.

Công nghệ WAAP hiện đại mang lại khả năng phòng thủ chủ động và toàn diện cho hệ thống máy chủ. Một bộ giải pháp WAAP tiêu chuẩn có thể cung cấp:

• Web Application Firewall (WAF)
• Bảo vệ API
• Chống bot tự động
• Giảm thiểu DDoS
• Phát hiện hành vi bất thường

Tại Việt Nam, các tổ chức có thể tham khảo trực tiếp giải pháp bảo mật WAAP do VinaHost cung cấp. Dịch vụ này được thiết kế tối ưu, phù hợp với hạ tầng mạng và nhu cầu bảo mật đặc thù của các doanh nghiệp trong nước.

Ưu điểm nổi bật của dịch vụ WAAP tại VinaHost

• Bảo vệ đa lớp toàn diện: kết hợp WAF, API Protection, chống DDoS và quản lý bot trên nền tảng đám mây.
• Duy trì hiệu suất và ổn định: ứng dụng luôn phản hồi nhanh và đáng tin cậy.
• Tiết kiệm chi phí vận hành: không cần đầu tư phần cứng và hệ thống bảo mật riêng lẻ.
• Quản lý tập trung: theo dõi và phản ứng mối đe dọa qua một giao diện duy nhất.
• Giảm gián đoạn dịch vụ: bảo vệ hoạt động kinh doanh liên tục.
• Bảo vệ danh tiếng thương hiệu: giảm rủi ro mất lòng tin từ khách hàng và đối tác.

7. Checklist kiểm tra nhanh BOLA (Dành cho Dev trước khi Deploy)

Trước khi đưa ứng dụng/API vào vận hành, các lập trình viên nên rà soát các điểm sau để giảm thiểu rủi ro Broken Object Level Authorization (BOLA):

Kết luận

Bảo mật API trước lỗ hổng Broken Object Level Authorization (BOLA) không thể chỉ dựa vào cơ chế xác thực đăng nhập ban đầu hay việc che giấu bằng chuỗi ID ngẫu nhiên (UUID). Để ngăn chặn triệt để nguy cơ rò rỉ dữ liệu và xâm phạm toàn vẹn hệ thống, doanh nghiệp bắt buộc phải thiết lập logic kiểm tra phân quyền (Authorization) khắt khe trên từng request.

Đừng thụ động chờ đợi tin tặc rà quét và khai thác lỗi logic trong mã nguồn. Hãy chủ động thiết lập màng lọc bảo mật đa lớp tự động. Với giải pháp WAAP (Web Application & API Protection) tại VinaHost, hệ thống API của doanh nghiệp sẽ được bảo vệ toàn diện 24/7 trước các hành vi thao túng ID, botnet và các lỗ hổng OWASP Top 10 mới nhất.

Mời bạn truy cập vào blog của VinaHost TẠI ĐÂY để theo dõi thêm nhiều bài viết mới. Hoặc nếu bạn muốn được tư vấn thêm về dịch vụ thì có thể liên hệ với chúng tôi qua:

• Email: support@vinahost.vn
• Hotline: 1900 6046
• Livechat: https://livechat.vinahost.vn/chat.php