Restricted Domains: Nghệ Thuật Giới Hạn Quyền Lực Trong Kiến Trúc Backend

Tiếp nối khái niệm về domains và domains_allow_all_routes, chúng ta tiến đến một khái niệm bảo mật tinh vi hơn: Restricted Domains (Các tên miền bị hạn chế).

Nếu domains_allow_all_routes là "thẻ bài miễn tử" cấp toàn quyền, thì Restricted Domains lại là "vòng kim cô" nhằm trói buộc những tên miền cụ thể, chỉ cho phép chúng hoạt động trong một khuôn khổ cực kỳ chật hẹp.

Đoạn cấu hình bạn cung cấp diễn giải một cơ chế bảo mật rất thông minh và phổ biến trong việc thiết kế API Gateway hoặc Reverse Proxy nội bộ.

1. Giải phẫu Cơ Chế Hoạt Động (Behavior)

Điểm thú vị nhất của cấu hình này nằm ở nguyên tắc hoạt động ngược: Default Allow (Mặc định cho phép) đối với các domain không nằm trong danh sách, và Explicit Restrict (Giới hạn rõ ràng) đối với các domain có mặt trong danh sách.

• Key (Khóa): Chính là định danh ngắn gọn của tên miền mà ta đã định nghĩa ở mảng domains (ví dụ: 'tracking', 'intl').

• Value (Giá trị): Một mảng chứa các route (đường dẫn API) mà domain đó được phép truy cập. Có thể dùng wildcard * để đại diện cho tất cả các đường dẫn con.

Nguyên lý vận hành:

1. Khi một request đến từ domain 'tracking'.

2. Hệ thống phát hiện 'tracking' có mặt trong danh sách Restricted Domains.

3. Hệ thống sẽ kiểm tra xem đường dẫn (route) của request đó có khớp với các mẫu được khai báo (ví dụ: /orders/tracking/*) hay không.

4. Nếu khớp: Cho phép đi qua.

5. Nếu không khớp (ví dụ: truy cập /api/users): Chặn đứng (thường trả về lỗi 403 Forbidden).

6. Mặt khác: Nếu request đến từ một domain không nằm trong danh sách này (ví dụ domain 'app'), nó sẽ được tự do truy cập mọi route (trừ khi bị giới hạn bởi các cơ chế bảo mật khác).

2. Tại sao lại cần "Vòng Kim Cô" này? (Ứng dụng thực tế)

Mô hình này giải quyết triệt để bài toán Least Privilege (Đặc quyền tối thiểu) cho các dịch vụ vệ tinh hoặc các module hướng ngoại (public-facing).

Ví dụ kinh điển: Hệ thống Tra cứu đơn hàng (Tracking)

Hãy nhìn vào ví dụ trong cấu hình:

PHP

'tracking' => [
    '/orders/tracking/search',
    '/orders/tracking/*',
]

• Hệ thống tracking (tracking.example-app.com) là một trang web Public, nơi bất kỳ người dùng nào cũng có thể lên gõ mã vận đơn để tra cứu.

• Bởi vì nó Public, nó là mục tiêu dễ bị tấn công nhất (bị scan API, DDoS nhẹ, hoặc exploit).

• Nếu không có Restricted Domains, một hacker có thể tìm ra lỗ hổng trên domain tracking và từ đó gọi vòng sang các API nội bộ nhạy cảm khác trên cùng một server backend (như /api/admin/users/delete).

• Nhờ có cấu hình này: Ngay cả khi hacker khai thác được một lỗ hổng SSRF trên frontend của trang Tracking để ép nó gọi các API khác, thì ở tầng Backend/Middleware, hệ thống cũng chỉ cho phép domain tracking gọi duy nhất cụm API /orders/tracking/*. Mọi nỗ lực "vượt rào" sang /api/admin đều bị bóp nghẹt ngay lập tức.

3. Sức Mạnh Của Wildcard (*)

Việc hỗ trợ wildcard (*) như trong mẫu /orders/tracking/* là một thiết kế rất khéo léo.

• Thay vì lập trình viên phải liệt kê thủ công từng route một (ví dụ: /orders/tracking/history, /orders/tracking/status, /orders/tracking/detail/...), wildcard cho phép gom toàn bộ một "Module" lại dưới một ô.

• Điều này giúp file cấu hình ngắn gọn, dễ bảo trì, và giảm thiểu lỗi "quên cấu hình" khi hệ thống mở rộng thêm các API con mới trong tương lai.

Tóm lại, Restricted Domains là cách các kiến trúc sư phần mềm "cách ly" các rủi ro. Bằng cách nhốt những ứng dụng có tính rủi ro cao (như các trang public) vào một không gian hẹp, họ bảo vệ an toàn cho phần cốt lõi của toàn bộ hệ thống.