Xây dựng MCP server thì dễ. Đặc tả yêu cầu gì trước khi ra mắt?

Yêu cầu nào của đặc tả MCP áp dụng trước khi máy chủ ra mắt?

Xây dựng một MCP server cơ bản không cần nhiều mã. Phần khó hơn là đáp ứng các quy tắc bảo mật trong đặc tả chính thức. Một số quy tắc là yêu cầu bắt buộc, viết ở dạng MUST. Một số khác là khuyến nghị, được viết là SHOULD, và một số được giao cho người xây dựng và triển khai máy chủ. Bài này sắp xếp chúng thành các nhóm đó, dựa trên trang xác thực và trang công cụ (bản sửa đổi 2026-07-28), cùng trang thực hành bảo mật chính thức ^[1][2][3].

Đặc tả cũng không phải là nguồn hướng dẫn duy nhất. Cheat Sheet bảo mật MCP của OWASP bổ sung các biện pháp kiểm soát mà đặc tả không bắt buộc, và một số trong đó nghiêm ngặt hơn ^[4]. Khi lên kế hoạch ra mắt, hãy tách hai nguồn này ra, vì một máy chủ có thể vượt qua rà soát theo đặc tả nhưng vẫn để lộ lỗ hổng.

Những quy tắc về token nào là bắt buộc?

Xác thực là tùy chọn trong đặc tả, nhưng một MCP server từ xa dùng xác thực phải kiểm tra token được cấp cho ai. Các máy chủ HTTP tuân theo đặc tả xác thực SHOULD tuân thủ nó ^[1]. Đặc tả nói rằng máy chủ MUST xác thực rằng access token được cấp riêng cho nó với tư cách là đối tượng dự kiến (audience), theo RFC 8707 Section 2 ^[1]. Máy chủ cũng MUST chỉ chấp nhận token hợp lệ cho tài nguyên của chính nó, và MUST NOT chấp nhận hay chuyển tiếp bất kỳ token nào khác ^[1].

Trên thực tế, điều này loại bỏ một lối tắt phổ biến: chuyển tiếp token mà client gửi cho một API phía sau. Token được cấp cho máy chủ của bạn không phải là token dành cho dịch vụ của bên khác, và máy chủ của bạn không nên chuyển nó đi. Nếu bạn không xác định được token trong một yêu cầu thuộc về ai, hãy coi yêu cầu đó là chưa được ủy quyền.

OWASP nhấn mạnh cùng điểm từ phía khác. Tài liệu này khuyên kiểm tra ủy quyền trên mọi yêu cầu được bảo vệ, vì giao thức Streamable HTTP hiện tại không có phiên ở tầng giao thức ^[4]. Hãy kiểm tra token ở mỗi lệnh gọi, không chỉ một lần khi kết nối.

Máy chủ proxy có cần sự đồng ý riêng cho từng client không?

Có, khi máy chủ đứng trước một API bên thứ ba. Trang thực hành bảo mật nói rằng máy chủ proxy của MCP MUST triển khai sự đồng ý riêng cho từng client và các biện pháp bảo mật phù hợp để ngăn tấn công confused deputy ^[3]. Trang này giải thích rủi ro: kẻ tấn công có thể khai thác các máy chủ proxy của MCP kết nối tới API bên thứ ba, tạo ra lỗ hổng confused deputy ^[3].

Lỗi này trông như sau. Một proxy giữ một thông tin xác thực có quyền rộng đối với API bên thứ ba. Một client chưa từng được phê duyệt yêu cầu proxy thực hiện thao tác, và proxy dùng đặc quyền của chính nó thay vì quyền của người dùng lẽ ra phải được hỏi. Sự đồng ý riêng cho từng client là biện pháp ngăn một client sử dụng quyền truy cập mà người dùng đã cấp cho client khác.

Đặc tả có yêu cầu người dùng phê duyệt mọi lệnh gọi công cụ không?

Không. Trang công cụ nói rằng giao thức không bắt buộc một mô hình tương tác người dùng cụ thể nào. Điều nó nói là client SHOULD yêu cầu người dùng xác nhận với các thao tác nhạy cảm, và SHOULD hiển thị đầu vào của công cụ trước khi gọi máy chủ ^[2].

Cũng trang đó liệt kê việc làm sạch kết quả công cụ là một yêu cầu MUST đối với máy chủ ^[2]. Vì vậy, phần bắt buộc với máy chủ là kiểm tra đầu ra, còn bước phê duyệt là khuyến nghị dành cho client.

OWASP có lập trường nghiêm ngặt hơn. Tài liệu này khuyên không bao giờ tự động phê duyệt lệnh gọi công cụ, đặc biệt trong các thiết lập nhiều máy chủ ^[4]. Nếu một công cụ có thể xóa dữ liệu, chi tiền hoặc chia sẻ thông tin cá nhân, hãy xây bước xác nhận vào máy chủ hoặc client của riêng bạn, thay vì phụ thuộc vào hành vi mặc định của client. Chỉ đặt xác nhận cho các công cụ đó. Hỏi xác nhận ở mọi lệnh đọc có nguy cơ khiến người dùng quen bấm đồng ý, nên đây là quyết định thiết kế, không phải quy tắc của đặc tả.

Máy chủ cục bộ có tuân theo cùng các quy tắc không?

Không phải lúc nào cũng vậy. Trang xác thực tách riêng các transport. Các triển khai dùng HTTP được kỳ vọng tuân theo đặc tả xác thực. Các triển khai dùng transport STDIO SHOULD NOT tuân theo đặc tả này, và thay vào đó lấy thông tin xác thực từ môi trường ^[1].

Sự khác biệt này quan trọng với một công cụ chạy cục bộ. Một máy chủ được khởi động như tiến trình con không cần luồng OAuth để truy cập API của chính nó, nhưng vẫn cần giữ thông tin xác thực ngoài mã nguồn và ngoài nhật ký. Tránh đặt bí mật trong dòng lệnh, vì lịch sử shell và danh sách tiến trình là nơi dễ làm rò rỉ chúng. Nếu sau này bạn mở cùng máy chủ đó qua HTTP, các máy chủ HTTP SHOULD tuân theo các quy tắc đó.

Các hướng dẫn bảo mật bổ sung điều gì so với đặc tả?

Các hướng dẫn bảo mật đi xa hơn mức tối thiểu của đặc tả. Cheat Sheet bảo mật MCP của OWASP khuyến nghị ghim định nghĩa công cụ bằng mã băm mật mã và kiểm tra chúng trước mỗi lần chạy ^[4]. Tài liệu này cũng khuyên coi mọi phản hồi của công cụ là dữ liệu không đáng tin, kể cả phản hồi từ những máy chủ bạn đã phê duyệt ^[4].

Nó còn thêm một quy tắc đặc quyền tối thiểu. Hãy cấp cho mỗi MCP server đúng quyền tối thiểu cần cho chức năng của nó, và dùng thông tin xác thực riêng, có phạm vi cho từng máy chủ, thay vì dùng chung một token cho nhiều máy chủ ^[4]. Một máy chủ đọc thư không nên giữ token vừa có thể đọc vừa có thể sửa thư.

Các biện pháp này không phải là yêu cầu để đạt tuân thủ, nên một máy chủ có thể qua được kiểm tra theo đặc tả mà không có chúng. Chúng quan trọng nhất khi mô tả công cụ hoặc kết quả công cụ đến từ một bên mà bạn không kiểm soát.

Đặc tả để ngỏ những gì?

Đặc tả để người xây dựng tự quyết một số việc. Nó không yêu cầu kiểm tra nội dung mô tả công cụ. Trang công cụ yêu cầu máy chủ kiểm tra đầu vào công cụ, triển khai kiểm soát truy cập, giới hạn tốc độ lệnh gọi công cụ và làm sạch đầu ra công cụ, nhưng không có yêu cầu MUST nào về chính nội dung mô tả ^[2]. Máy chủ của bạn phải quyết định cách rà soát các mô tả mà nó công bố, và client của bạn phải quyết định mức độ tin cậy với chúng.

Đặc tả để ngỏ thiết kế giao diện phê duyệt cho bên triển khai. Trang công cụ cũng khuyến nghị ghi nhật ký việc sử dụng công cụ cho mục đích kiểm toán ^[2], nên thiết kế phê duyệt và nhật ký kiểm toán do bạn xây dựng. Hai client có thể xử lý cùng một công cụ rủi ro theo những cách rất khác nhau, đó là lý do hành vi của từng client cần được kiểm thử, không chỉ máy chủ.

Nên kiểm tra gì trước khi ra mắt MCP server?

Dùng danh sách này làm bước kiểm tra trước khi ra mắt. Mỗi mục nêu nguồn của yêu cầu.

• Đối tượng của token: từ chối mọi token không được cấp cho máy chủ của bạn. Đây là yêu cầu MUST trong đặc tả ^[1].
• Không chuyển tiếp: không chuyển token của client cho API phía sau. Đây là yêu cầu MUST trong đặc tả ^[1].
• Sự đồng ý: nếu bạn đứng trước một API bên thứ ba, hãy ghi lại riêng từng client đã được đồng ý. Đây là yêu cầu MUST trong đặc tả đối với máy chủ proxy ^[3].
• Kết quả: làm sạch kết quả công cụ trước khi trả về. Đây là yêu cầu MUST trong đặc tả đối với máy chủ ^[2].
• Ủy quyền ở mọi lệnh gọi: kiểm tra token ở mọi yêu cầu được bảo vệ, không chỉ một lần khi kết nối ^[4].
• Xác nhận: yêu cầu người dùng xác nhận trước thao tác nhạy cảm và hiển thị tham số sẽ được gửi. Đây là khuyến nghị SHOULD dành cho client trong đặc tả, và OWASP khuyên xác nhận rõ ràng với thao tác xóa dữ liệu, chi tiền hoặc chia sẻ dữ liệu ^[2][4].
• Phạm vi: cấp cho mỗi máy chủ quyền hẹp nhất và thông tin xác thực riêng ^[4].
• Định nghĩa: ghim định nghĩa công cụ, kiểm tra chúng trước mỗi lần chạy, và yêu cầu rà soát lại mỗi khi chúng thay đổi ^[4].

Một biên bản rà soát trước khi ra mắt nên ghi những gì?

Một bản ghi ngắn bằng văn bản giúp việc rà soát có thể lặp lại. Với mỗi máy chủ, hãy giữ danh sách công cụ và đánh dấu mức tác động của từng công cụ: chỉ đọc, thay đổi dữ liệu, hoặc ảnh hưởng đến tiền hoặc dữ liệu cá nhân. Bên cạnh mỗi công cụ, ghi có cần bước xác nhận hay không và ai chịu trách nhiệm quyết định đó. Ghi lại transport mà máy chủ dùng, thông tin xác thực lấy từ đâu, và những client nào được phép gọi nó.

Bản ghi cũng nên trỏ tới kết quả kiểm thử ở mục tiếp theo. Một người rà soát thấy công cụ được đánh dấu là ảnh hưởng đến dữ liệu cá nhân, mà không có bước xác nhận và không có bằng chứng kiểm thử, đã tìm ra lỗ hổng mà không cần đọc mã.

Làm thế nào để kiểm thử từng quy tắc trước khi ra mắt?

Biến mỗi quy tắc bắt buộc thành một bài kiểm thử có thể chạy trên máy chủ staging:

• Sai đối tượng: gửi một token được cấp cho tài nguyên khác. Máy chủ phải từ chối, và lỗi phải tuân theo quy tắc xử lý lỗi của OAuth 2.1 ^[1].
• Client chưa đăng ký: gửi yêu cầu từ một client chưa có sự đồng ý được ghi nhận tới proxy. Yêu cầu phải thất bại cho đến khi có sự đồng ý ^[3].
• Kết quả độc hại: trả về một kết quả công cụ có chứa chỉ dẫn, chẳng hạn một dòng bảo mô hình bỏ qua các quy tắc trước đó. Kiểm tra xem bước làm sạch có loại bỏ hoặc gắn nhãn nó trước khi nó đến mô hình hay không ^[2][4].
• Chuỗi lệnh gọi dồn dập: gửi nhiều lệnh gọi tới một công cụ trong thời gian ngắn. Kiểm tra giới hạn tốc độ có giữ được không, vì máy chủ phải giới hạn tốc độ lệnh gọi công cụ ^[2].
• Rà soát nhật ký: tìm token và thông tin xác thực trong nhật ký và thông báo lỗi. Kết quả tìm kiếm phải không trả về gì.

Chạy các kiểm thử này ở mỗi lần ra mắt, và chạy lại sau mọi thay đổi định nghĩa công cụ. OWASP khuyên yêu cầu rà soát lại khi định nghĩa thay đổi ^[4].

Hãy coi danh sách này là mức sàn, không phải mức trần. Chạy các kiểm thử trên máy chủ staging trước lần ra mắt đầu tiên.