Phần lớn các đội ngũ coi bảo mật API là một bài toán xác thực. Họ phát hành token, kiểm tra token trên mọi tuyến đường, rồi xem như đã xong việc. Sau đó một người kiểm thử đổi đúng một con số trong URL và đọc được hóa đơn của khách hàng khác.

Khoảng trống giữa đã xác thực và được phép chính là nơi phần lớn các vụ xâm phạm API thực tế trú ngụ, và đó không phải loại lỗi mà một công cụ quét tìm ra một cách đáng tin cậy. Công cụ tự động nhìn thấy một token hợp lệ và một phản hồi 200 rồi báo là thành công. Chỉ có con người hiểu quy tắc nghiệp vụ của bạn mới nhận ra rằng phản hồi đó chứa dữ liệu của người khác.

Sự phân biệt cốt lõi: Xác thực chứng minh ai đang gọi. Phân quyền quyết định người gọi cụ thể đó được xem hay thay đổi những gì, và nó phải được cưỡng chế trên từng đối tượng, trong từng yêu cầu, ở tầng dữ liệu. Gần như mọi lỗ hổng API nghiêm trọng đều là thất bại của vế thứ hai trong khi vế thứ nhất hoạt động hoàn hảo.

Vì sao lỗi phân quyền ở cấp đối tượng chiếm ưu thế

Lỗi API nghiêm trọng phổ biến nhất cũng là lỗi dễ mô tả nhất.

Điểm cuối của bạn là /api/invoices/48213. Người gọi đã được xác thực, nên trình xử lý lấy hóa đơn 48213 và trả về. Không ai kiểm tra rằng hóa đơn 48213 thuộc về người gọi. Đổi con số, nhận hóa đơn của người khác. API đã chạy đúng như những gì được viết ra; chính cách viết mới là cái sai.

Chuyện này mở rộng quy mô theo hướng bất lợi cho bạn và có lợi cho kẻ tấn công. Định danh tăng tuần tự cho phép ai đó liệt kê toàn bộ tập dữ liệu của bạn chỉ bằng một vòng lặp. Chuyển sang định danh khó đoán giúp được một chút nhưng không phải là cách sửa, bởi định danh vẫn rò rỉ qua các điểm cuối khác, qua tệp xuất dữ liệu và qua email.

Cách sửa phải mang tính cấu trúc chứ không phải chắp vá. Quyền sở hữu phải được kiểm tra ngay trong chính truy vấn, tức là lấy hóa đơn thuộc về khách hàng này với định danh này, thay vì lấy hóa đơn ra rồi hy vọng một đoạn mã nào đó phía sau sẽ kiểm tra giúp. Hãy đặt việc cưỡng chế đó ở tầng truy cập dữ liệu để nó không thể bị bỏ quên trong một controller mới, viết sáu tháng sau bởi một người chưa từng đọc đoạn văn này.

Cùng một kiểu thất bại cũng áp dụng cho chức năng chứ không chỉ cho đối tượng. Nếu một điểm cuối quản trị chỉ được bảo vệ bởi sự thật rằng giao diện quản trị không liên kết tới nó cho người dùng thường, thì nó hoàn toàn không được bảo vệ.

Những lỗ hổng bảo mật API thực sự hay gặp

Ngoài phân quyền, một nhóm nhỏ vấn đề chiếm phần lớn các phát hiện. Tài liệu tham chiếu tiêu chuẩn ở đây là OWASP API Security Top 10, và OWASP cập nhật danh sách này theo chu kỳ, nên hãy đọc phiên bản hiện hành thay vì một bản tóm tắt.

Trả về nhiều hơn những gì giao diện hiển thị. Một điểm cuối trả về toàn bộ đối tượng người dùng vì làm vậy tiện hơn, còn giao diện chỉ hiển thị ba trường. Mười hai trường còn lại, bao gồm token đặt lại mật khẩu và điểm rủi ro nội bộ, vẫn nằm nguyên trong phản hồi. Bất kỳ ai mở tab mạng của trình duyệt đều có chúng. Hãy tuần tự hóa một cách có chủ đích: dựng phản hồi từ những trường được nêu tên thay vì đổ nguyên một model ra ngoài.

Gán hàng loạt ở chiều ngược lại. Đây là hình ảnh phản chiếu của lỗi trên. Một điểm cuối cập nhật hồ sơ nhận mọi trường gửi tới và ghi thẳng vào bản ghi, nên người gọi chỉ cần thêm "role": "admin" là tự thăng cấp cho mình. Hãy ràng buộc dữ liệu một cách tường minh vào danh sách các trường được phép thay vì nhận trọn gói phần thân yêu cầu.

Tiêu thụ không giới hạn. Không có giới hạn, một người gọi có thể yêu cầu một triệu bản ghi mỗi trang, chạy các truy vấn tìm kiếm tốn kém trong vòng lặp, hoặc kích hoạt hàng nghìn lượt đặt lại mật khẩu. Đây không chỉ là chuyện từ chối dịch vụ: khi mỗi yêu cầu tiêu tiền của bạn, như trường hợp có một mô hình ngôn ngữ nằm sau điểm cuối, thì đó là một đòn tấn công vào hóa đơn. Giới hạn tần suất phải đặt theo từng bên tiêu thụ và từng điểm cuối, với các thao tác đắt đỏ bị siết chặt hơn các thao tác rẻ.

Kiểm kê và niềm tin vào bên thứ ba

Điểm cuối không tài liệu và bị bỏ quên. Phiên bản hai đang chạy và có tài liệu, phiên bản một vẫn sống với logic phân quyền cũ, còn một API staging mang dữ liệu thật thì truy cập được từ Internet. Kẻ tấn công tìm chính xác những thứ này. Hãy duy trì danh sách kiểm kê mọi API đã triển khai, mọi phiên bản và mọi môi trường, rồi ngừng vận hành chúng một cách có chủ đích thay vì để mặc theo quán tính.

Tin tưởng những hệ thống mà bạn gọi tới. API của bạn tiêu thụ các API khác, và phản hồi của chúng rơi thẳng vào cơ sở dữ liệu và phần hiển thị của bạn. Hãy kiểm chứng những gì quay về thay vì mặc định rằng một đối tác thì an toàn. Sự cố hay thay đổi đặc tả phía họ rất thường xuất hiện trở lại dưới dạng một lỗi mang tên bạn. Hướng dẫn của chúng tôi về tích hợp API bên thứ ba bàn về mặt độ tin cậy của chính mối quan hệ đó.

Làm cho phần xác thực đúng đắn

Xác thực là phần mà hầu hết các đội làm tương đối ổn, nên phần này nói về những chi tiết nhỏ có thể phá hỏng nó.

Hãy dùng token truy cập ngắn hạn kèm cơ chế làm mới, thay vì những khóa dài hạn không bao giờ hết hạn. Một thông tin đăng nhập bị lộ mà có hiệu lực vĩnh viễn là một vụ xâm phạm vĩnh viễn; một thông tin hết hạn sau mười lăm phút chỉ là một sự cố có điểm kết thúc rõ ràng.

Hãy giới hạn phạm vi của token thật hẹp. Một token cấp cho tích hợp báo cáo thì không nên có khả năng tạo người dùng. Scope cho phép bạn cưỡng chế điều đó tập trung, thay vì trông chờ mỗi trình xử lý tự kiểm tra.

Hãy kiểm chứng token cho đúng, mà phần lớn nghĩa là không chấp nhận thuật toán do chính token khai báo. Hãy cố định thuật toán ký mà bạn mong đợi, kiểm tra bên phát hành và bên nhận, và kiểm tra hạn dùng. Có sẵn những thư viện làm việc này theo mặc định; chỗ trú ngụ của sai lầm luôn là phần kiểm chứng tự viết tay.

Hãy xoay vòng thông tin đăng nhập theo lịch và cung cấp cách để bên tiêu thụ xoay vòng mà không gián đoạn, thường là bằng cách chấp nhận hai khóa hợp lệ trong giai đoạn chuyển đổi. Nếu việc xoay vòng gây gián đoạn dịch vụ, sẽ không ai làm nó cả.

Cuối cùng, đừng bao giờ đặt thông tin đăng nhập trong URL. Chuỗi truy vấn kết thúc trong nhật ký máy chủ, lịch sử trình duyệt, nhật ký proxy và tiêu đề referrer. Hãy dùng header.

Một bài kiểm thử xâm nhập thực sự tìm ra điều gì

Quét tự động và kiểm thử thủ công tìm ra những thứ khác nhau, và bạn cần cả hai vì những lý do khác nhau.

Công cụ quét giỏi ở việc phát hiện thư viện phụ thuộc có lỗ hổng đã biết, header bảo mật bị thiếu, cấu hình TLS sai và các dạng tiêm nhiễm hiển nhiên. Hãy chạy chúng liên tục trong pipeline, bởi chúng rẻ và chúng bắt được các bước lùi.

Điều chúng không làm được là suy luận về nghiệp vụ của bạn. Một người kiểm thử phát hiện rằng điểm cuối mã giảm giá có thể gọi lặp lại để cộng dồn ưu đãi, rằng một tính năng trả phí vẫn dùng được ở gói miễn phí nếu gọi thẳng API, hoặc rằng hủy đơn sau khi đã giao sẽ kích hoạt hoàn tiền mà không kiểm tra tồn kho. Đó mới là những phát hiện làm mất tiền thật, và chúng chỉ lộ ra khi có người hiểu API của bạn tồn tại để làm gì.

Riêng với API, hãy yêu cầu bài kiểm thử bao gồm phần kiểm tra phân quyền xuyên vai trò, nghĩa là người kiểm thử giữ thông tin đăng nhập của hai khách hàng khác nhau và thử một cách có hệ thống việc chạm tới dữ liệu của tài khoản này bằng token của tài khoản kia. Chỉ riêng bài tập đó đã tìm ra nhiều hơn tất cả những thứ còn lại cộng lại. Bài tổng quan của chúng tôi về các loại kiểm thử xâm nhập giải thích nên trao cho người kiểm thử bao nhiêu quyền truy cập, và việc đưa cho họ tài liệu cùng thông tin đăng nhập cho kết quả tốt hơn hẳn so với một bài kiểm thử mù.

Về ngân sách, kiểm thử tập trung vào API thường bắt đầu từ khoảng £3,000 cho một API nhỏ và có tài liệu tốt, lên tới £15,000 hoặc hơn cho một bề mặt lớn với nhiều vai trò và nhiều tích hợp. Hướng dẫn chi phí kiểm thử xâm nhập của chúng tôi phân tích những yếu tố tạo nên khoảng giá đó.

Ghi nhật ký đủ để còn điều tra được

Khác biệt giữa một sự cố và một thảm họa thường nằm ở chỗ bạn có tái dựng được chuyện đã xảy ra hay không.

Hãy ghi lại các sự kiện xác thực, các lần phân quyền thất bại, và mọi thao tác làm thay đổi trạng thái, kèm theo danh tính người gọi, đối tượng đích và một mã tương quan. Riêng các lần phân quyền thất bại chính là hệ thống cảnh báo sớm của bạn: một tích hợp hợp lệ gần như không tạo ra lần nào, nên một loạt thất bại dồn dập nghĩa là có ai đó đang dò tìm.

Đừng ghi chính các giá trị nhạy cảm. Token, thông tin thẻ và dữ liệu cá nhân nằm trong tệp nhật ký sẽ biến một vụ xâm phạm đang được khoanh vùng thành một vụ phải khai báo với cơ quan quản lý.

Hãy cảnh báo theo mẫu hình chứ không theo khối lượng. Một người gọi tạo ra các lần phân quyền thất bại trên nhiều định danh đối tượng khác nhau là dấu hiệu của việc liệt kê đang diễn ra, và điều đó đáng để đánh thức ai đó lúc nửa đêm. Tổng tỷ lệ lỗi thì không.

Hãy lưu giữ đủ lâu để nhật ký còn hữu ích. Các vụ xâm nhập thường bị phát hiện nhiều tuần sau khi chúng bắt đầu, và ba mươi ngày nhật ký thường là quá ngắn để tìm ra điểm xâm nhập ban đầu.

Hãy kiểm thử đúng cái API bạn đã phát hành

Mecanik cung cấp dịch vụ kiểm thử bảo mật ứng dụng với trọng tâm là các lỗi phân quyền và lỗi logic nghiệp vụ mà công cụ tự động bỏ sót, bao gồm cả kiểm thử chéo giữa các tài khoản bằng thông tin đăng nhập thật của nhiều vai trò khác nhau.

Chúng tôi làm việc từ đặc tả và tài liệu của bạn thay vì đoán mò bề mặt tấn công, và như một hệ quả phụ, cách làm đó phát hiện ra các điểm cuối không tài liệu cùng những phiên bản bị bỏ lại phía sau. Khi công việc mở rộng sang hạ tầng và mạng, dịch vụ kiểm thử xâm nhập của chúng tôi bao phủ phần đó. Còn nếu bạn vẫn đang thiết kế API, hướng dẫn của chúng tôi về chi phí phát triển API tùy chỉnh chỉ rõ chỗ đứng của phân quyền, giới hạn tần suất và ghi nhật ký ngay trong bản dựng, thay vì gắn thêm chúng về sau.

Hãy gửi cho chúng tôi đặc tả và mô tả các vai trò của bạn, chúng tôi sẽ chỉ ra rủi ro đang tập trung ở đâu.

Bài viết liên quan: Kiểm thử xâm nhập tại Vương quốc Anh - Điều gì chờ bạn năm 2026 , Tuân thủ kỹ thuật GDPR cho các nhà phát triển tại Anh , Cloudflare Zero Trust: Hướng dẫn bảo mật truy cập doanh nghiệp , Giải thích OWASP Top 10 cho chủ doanh nghiệp .

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

Lỗ hổng bảo mật API phổ biến nhất là gì? Đó là lỗi phân quyền ở cấp đối tượng, khi một người gọi đã xác thực có thể chạm tới dữ liệu của người dùng khác chỉ bằng cách đổi một định danh trong yêu cầu. Phần xác thực vẫn chạy đúng, nhưng không có gì kiểm tra rằng đối tượng được yêu cầu thuộc về người gọi. Vì vậy quyền sở hữu phải được cưỡng chế ngay trong truy vấn.

Chỉ dùng API key thì đã đủ an toàn chưa? Chưa đủ. Những khóa dài hạn không bao giờ hết hạn biến mọi rò rỉ thành một vụ xâm phạm vĩnh viễn. Hãy dùng token truy cập ngắn hạn kèm cơ chế làm mới, giới hạn phạm vi đúng bằng những gì bên tiêu thụ thực sự cần, hỗ trợ xoay vòng không gián đoạn, và luôn gửi chúng trong header thay vì trong URL.

Quét tự động có bảo mật được API không? Không, dù vẫn rất đáng chạy liên tục. Công cụ quét tìm ra thư viện phụ thuộc có lỗ hổng đã biết, header bị thiếu và các dạng tiêm nhiễm hiển nhiên. Chúng không suy luận được về quy tắc nghiệp vụ của bạn, nên bỏ sót chuyện cộng dồn khuyến mãi, tính năng trả phí dùng được ở gói miễn phí và truy cập dữ liệu xuyên tài khoản.

Kiểm thử xâm nhập API tốn bao nhiêu tiền? Thường bắt đầu từ khoảng £3,000 cho một API nhỏ và có tài liệu tốt, lên tới £15,000 hoặc hơn cho một bề mặt lớn với nhiều vai trò và nhiều tích hợp. Chi phí bị chi phối bởi số lượng điểm cuối, số vai trò khác nhau, và việc bạn có cung cấp tài liệu cùng thông tin đăng nhập hay không.

API nên ghi nhật ký những gì cho mục đích bảo mật? Các sự kiện xác thực, các lần phân quyền thất bại và mọi thao tác làm thay đổi trạng thái, mỗi mục kèm danh tính người gọi, đối tượng đích và một mã tương quan. Tuyệt đối không ghi token hay dữ liệu cá nhân. Hãy cảnh báo khi một người gọi tạo ra các lần phân quyền thất bại trên nhiều định danh khác nhau, vì đó là dấu hiệu của việc liệt kê.