HTTP 401 so với 403: Sự khác biệt là gì?
API Thu thập Dữ liệu Toàn cầu Không Rác truy xuất nội dung web công khai thông qua một trình mở khóa web được quản lý đồng thời vẫn tôn trọng yêu cầu xác thực, ủy quyền và các điều khiển truy cập.
TL;DR
- HTTP 401 so với 403: Sự khác biệt là gì có một ranh giới kỹ thuật chính xác. Một bài kiểm tra quyết định đơn giản là: liệu một thông tin xác thực danh tính hợp lệ hoặc được làm mới có thay đổi kết quả không? Nếu có, 401 là lựa chọn bình thường. Nếu máy chủ đã nhận diện danh tính mà chính sách vẫn từ chối hoạt động, 403 truyền đạt kết quả chính xác hơn. Một máy chủ cũng có thể sử dụng 404 trong các thiết kế bảo mật hạn chế để tránh tiết lộ rằng một tài nguyên tồn tại, nhưng lựa chọn đó nên được thực hiện một cách có chủ ý và nhất quán.
- Không có thông tin xác thực nào được gửi là một nguyên nhân phổ biến. Một route API được bảo vệ không nhận cookie phiên, tiêu đề ủy quyền hoặc chứng chỉ khách hàng, vì vậy máy chủ không thể thiết lập một nguyên tắc được xác thực và trả về 401.
- Ranh giới bảo mật thay đổi bước đi an toàn tiếp theo. Một 403 không phải là lời nhắc để thay đổi dấu hiệu danh tính, địa chỉ mạng hoặc tiêu đề yêu cầu cho đến khi chính sách thay đổi; nó là một từ chối ủy quyền phải được tôn trọng.
- Đối với 401, hãy làm theo kế hoạch xác thực đã công bố. Lấy hoặc làm mới thông tin xác thực hợp lệ chỉ thông qua quy trình danh tính được ủy quyền.
- 401 và 403 trong Thu thập Dữ liệu Web Công khai yêu cầu phân loại rõ ràng. Chỉ thu thập dữ liệu công khai hoặc được ủy quyền một cách thích hợp, giảm thiểu lưu lượng yêu cầu và bảo vệ bí mật khỏi các lời nhắc, nhật ký và kho lưu trữ. Quản lý trạng thái chính xác cải thiện độ tin cậy chính xác vì nó bảo vệ quyết định bảo mật thay vì làm mờ nó.
Một Mã yêu cầu Danh tính; cái khác từ chối Quyền
HTTP 401 và 403 đều là phản hồi lỗi của khách hàng, nhưng chúng mô tả các quyết định bảo mật khác nhau. Một 401 nói rằng yêu cầu thiếu thông tin xác thực xác thực hợp lệ cho tài nguyên mục tiêu. Một 403 nói rằng máy chủ hiểu yêu cầu và từ chối ủy quyền cho nó. Việc trộn lẫn chúng khiến khách hàng phải chọn hành động tiếp theo sai và làm cho nhật ký bảo mật khó hiểu hơn.
Các tên tạo ra sự nhầm lẫn. Cụm từ chuẩn cho 401 là Không được ủy quyền, nhưng ý nghĩa thực tế của nó gần với không được xác thực. Khách hàng có thể không gửi thông tin xác thực nào, thông tin xác thực đã hết hạn, thông tin xác thực cho khán giả sai hoặc thông tin xác thực mà máy chủ không thể xác thực. Một 403 thường có nghĩa là xác thực sẽ không cấp phép cho hoạt động yêu cầu theo danh tính và chính sách hiện tại.
Đối với công việc dữ liệu web công khai, không trạng thái nào nên được xem như một câu đố để vượt qua. Một người thu thập có thể sửa đổi thông tin xác thực còn thiếu của chính mình khi được ủy quyền sử dụng một cái, nhưng họ không nên tìm cách lách quanh quyết định ủy quyền. Phản hồi nên được phân loại, ghi lại và chuyển đến chủ sở hữu danh tính hoặc chính sách truy cập.
Quy tắc Trực tiếp cho HTTP 401 so với 403
Sử dụng 401 khi yêu cầu thiếu thông tin xác thực xác thực hợp lệ cho tài nguyên, và sử dụng 403 khi máy chủ từ chối quyền ủy quyền cho yêu cầu. Tiêu chuẩn Ngữ nghĩa HTTP định nghĩa cả hai phản hồi và yêu cầu phản hồi 401 bao gồm một thách thức xác thực áp dụng cho tài nguyên mục tiêu.
Một bài kiểm tra quyết định đơn giản là: liệu một thông tin xác thực danh tính hợp lệ hoặc được làm mới có thay đổi kết quả không? Nếu có, 401 là lựa chọn bình thường. Nếu máy chủ đã nhận diện danh tính mà chính sách vẫn từ chối hoạt động, 403 truyền đạt kết quả chính xác hơn. Một máy chủ cũng có thể sử dụng 404 trong các thiết kế bảo mật hạn chế để tránh tiết lộ rằng một tài nguyên tồn tại, nhưng lựa chọn đó nên được thực hiện một cách có chủ ý và nhất quán.
Cách mà Xác thực và Ủy quyền đạt được các Quyết định Khác nhau
Xác thực xác lập ai hoặc cái gì là người gọi. Nó xác thực một cookie phiên, thông tin xác thực API, chứng chỉ khách hàng, hoặc một bằng chứng khác được chấp nhận và liên kết yêu cầu với một danh tính. Sự thất bại ở giai đoạn này để lại máy chủ không có một nguyên tắc được xác thực hợp lệ cho hoạt động.
Ủy quyền đánh giá những gì danh tính đó có thể làm. Chính sách có thể phụ thuộc vào vai trò, quyền sở hữu, người thuê, trạng thái tài nguyên, khu vực mạng, thời gian hoặc một thuộc tính đã được xác nhận khác. Một người gọi có thể được xác thực đầy đủ nhưng vẫn thiếu quyền truy cập một bản ghi, thực thi một phương thức hoặc vào một khu vực quản trị.
Trải nghiệm của khách hàng nên phù hợp với giai đoạn. Phản hồi 401 có thể kích hoạt một luồng đăng nhập hoặc làm mới thông tin xác thực trong một ứng dụng được ủy quyền. Một 403 nên giải thích khả năng bị từ chối mà không tiết lộ chi tiết chính sách nhạy cảm. Lặp lại đăng nhập sau một 403 chính xác chỉ tái tạo cùng một quyết định.
| Kích thước | Tín hiệu A | Tín hiệu B |
|---|---|---|
| Trạng thái danh tính | Thiếu, không hợp lệ hoặc hết hạn | Đã biết và chấp nhận |
| Quyết định chính sách | Không đạt được với một nguyên tắc hợp lệ | Đã đạt được và bị từ chối |
| Mã điển hình | 401 Không được phép | 403 Bị từ chối |
| Hành động của khách hàng hữu ích | Lấy thông tin xác thực hợp lệ | Yêu cầu quyền hoặc chọn một hoạt động được phép |
Nguyên nhân Chung Mỗi Trạng thái Xuất hiện
Phân loại thông tin xác thực và trạng thái chính sách trước khi thay đổi yêu cầu ngăn ngừa vòng lặp tình cờ và thao tác không an toàn.
Không có thông tin xác thực nào được gửi
Một route API được bảo vệ không nhận cookie phiên, tiêu đề ủy quyền hoặc chứng chỉ khách hàng, vì vậy máy chủ không thể thiết lập một nguyên tắc được xác thực và trả về 401.
Xác thực thông tin không thành công
Chữ ký, người phát hành, đối tượng, thời gian hết hạn hoặc trạng thái phiên có thể không hợp lệ. Phản hồi vẫn là 401 vì chứng cứ được trình bày không thiết lập được một danh tính chấp nhận.
Danh tính hợp lệ thiếu vai trò
Tài khoản đã được xác thực nhưng không nắm giữ vai trò quản trị viên, biên tập viên, thanh toán hoặc vai trò cụ thể về tài nguyên cần thiết cho thao tác, do đó 403 là phù hợp.
Quyền sở hữu tài nguyên không khớp
Một người dùng có thể đọc hồ sơ của chính mình nhưng không thể đọc hồ sơ của người thuê khác. Xác thực thành công, sau đó ủy quyền cấp đối tượng từ chối quyền truy cập với 403 hoặc chính sách 404 có chủ ý.
Phương pháp hoặc trạng thái bị hạn chế
Một vai trò có thể đọc một tài nguyên nhưng không thể xóa nó, hoặc một thao tác có thể bị vô hiệu hóa sau khi tài nguyên đạt trạng thái khóa. Khả năng bị từ chối là một quyết định ủy quyền.
Chính sách mạng hoặc ứng dụng từ chối quyền truy cập
Một người gọi đã xác thực vẫn có thể ở bên ngoài vùng mạng cho phép hoặc không đáp ứng điều kiện chính sách truy cập khác. Chủ sở hữu chính sách nên xác nhận xem 403 hay phản hồi ít tiết lộ hơn là phù hợp.
Chẩn đoán Đường dẫn Danh tính Trước Đường dẫn Quyền
Cuộc điều tra nên chứng minh việc chấp nhận thông tin xác thực trước, sau đó đánh giá quyết định chính sách chính xác cho tài nguyên và phương pháp được yêu cầu.
- Ghi lại mã và thách thức. Trên 401, kiểm tra thách thức xác thực và xác nhận sơ đồ mong đợi bởi tài nguyên mà không ghi lại bí mật.
- Xác nhận sự hiện diện của thông tin xác thực một cách an toàn. Ghi nhận rằng một loại thông tin xác thực đã được gửi, thông tin về người phát hành và đối tượng của nó khi an toàn, và kết quả xác thực; không bao giờ sao chép bí mật vào vé hoặc ghi chép.
- Kiểm tra thời gian và trạng thái phiên. Các phiên hết hạn, thông tin xác thực bị thu hồi và lỗi đồng hồ thuộc về xác thực và thường dẫn đến 401.
- Giải quyết nguyên tắc đã xác thực. Xác minh tài khoản, danh tính dịch vụ, người thuê và các vai trò hiệu quả mà máy chủ thực sự công nhận.
- Đánh giá quyền truy cập chính xác. Kiểm tra quyền sở hữu tài nguyên, phương pháp đã yêu cầu, vai trò, điều kiện chính sách và trạng thái tài nguyên thay vì hỏi xem người dùng có thể truy cập ứng dụng chung hay không.
- So sánh một điều khiển cho phép. Một thao tác được biết đến là được phép cho cùng một danh tính xác nhận xác thực và thu hẹp vấn đề đến ủy quyền trên hành động bị từ chối.
- Xem xét chính sách công khai. Quyết định xem một tài nguyên riêng tư bị thiếu hoặc bị cấm nên trả về 403 hay một 404 đồng nhất, sau đó áp dụng quy tắc đó một cách nhất quán để tránh rò rỉ thông tin.
Sự phân biệt được nêu rõ ràng bởi Ngữ nghĩa HTTP và tham chiếu 401 của MDN, trong khi tham chiếu 403 của MDN cung cấp tài liệu kèm theo cho phản hồi bị cấm.
Những gì một Khách hàng API Nên làm
Một khách hàng nên phản hồi với vấn đề danh tính hoặc quyền truy cập mà máy chủ đã xác định, không xoay vòng qua các biến thể yêu cầu không liên quan.
- Đối với 401, theo sơ đồ xác thực đã công bố. Nhận hoặc làm mới thông tin xác thực hợp lệ chỉ thông qua luồng danh tính được ủy quyền.
- Đối với 403, dừng thao tác bị từ chối. Yêu cầu chủ sở hữu tài nguyên hoặc quản trị viên về quyền truy cập cần thiết khi mục đích kinh doanh là hợp pháp.
- Bảo vệ thông tin xác thực trong quá trình chẩn đoán. Chia sẻ ID yêu cầu và thông tin xác thực, không bao giờ chia sẻ cookie, mật khẩu, khóa riêng tư hoặc giá trị bearer đầy đủ.
- Đừng coi 403 là một trò chơi phát hiện bot. Chính sách quyền truy cập và các điều khoản của trang vẫn áp dụng cho các khách hàng tự động và thu thập dữ liệu.
Cách các Nhà thiết kế API Nên Trả về 401 và 403
Hành vi của máy chủ nên làm cho hành động an toàn tiếp theo của khách hàng trở nên rõ ràng trong khi giảm thiểu sự tiết lộ chính sách nhạy cảm.
Trả về 401 với thách thức xác thực phù hợp khi thông tin xác thực bị thiếu hoặc không hợp lệ. Giữ cho chi tiết lỗi đủ hữu ích để xác định sơ đồ và lớp xác thực rộng, nhưng tránh để lộ khóa ký, mã thông báo thô hoặc dấu vết xác thực nội bộ.
Trả về 403 sau khi một nguyên tắc hợp lệ được biết và chính sách từ chối hành động. Ghi lại quy tắc chính sách, nguyên tắc, người thuê, tài nguyên, phương thức và ID tương quan ở phía máy chủ. Thông điệp của khách hàng có thể vẫn ngắn gọn khi những chi tiết đó sẽ tiết lộ cấu trúc truy cập nhạy cảm.
Kiểm tra quyền truy cập theo đối tượng, không chỉ vai trò theo tuyến đường. Một người dùng với vai trò người đọc chung có thể vẫn bị hạn chế ở một khách thuê hoặc phạm vi quyền sở hữu. Các kiểm tra nhất quán tại ranh giới dữ liệu ngăn chặn một tuyến đường trả về 403 trên một đường mã nhưng rò rỉ cùng một bản ghi thông qua một đường khác.
Ma trận Quyết định cho 401 và 403
Trạng thái chính xác phụ thuộc vào kiến thức của máy chủ về người gọi và kết quả kiểm tra quyền.
| Trường hợp | Ý nghĩa | Phản hồi đề xuất |
|---|---|---|
| Không có thông tin xác thực | Danh tính chưa được thiết lập | 401 với thách thức xác thực |
| Thông tin xác thực không hợp lệ hoặc đã hết hạn | Bằng chứng danh tính không được chấp nhận | 401 và bắt đầu quy trình danh tính đã được ủy quyền |
| Danh tính hợp lệ, thiếu quyền | Danh tính đã biết nhưng thao tác bị từ chối | 403 và dừng thao tác |
| Tài nguyên riêng tư bị ẩn bởi chính sách | Sự tồn tại không được tiết lộ | 404 nhất quán có thể được lựa chọn theo thiết kế |
401 và 403 trong Thu thập Dữ liệu Web Công khai
Một trình thu thập dữ liệu sử dụng API Thu thập Dữ liệu Không Rác nên phân loại 401 và 403 như là kết quả truy cập trước khi phân tích nội dung. Tầng truy xuất được quản lý có thể trả lại nội dung trang, nhưng không thay thế thông tin xác thực, quyền, hoặc quy tắc của trang web mục tiêu.
Lưu trạng thái, URL cuối cùng, máy chủ mục tiêu, ID yêu cầu và mô tả an toàn về chế độ thông tin xác thực. Giữ các trang đăng nhập và các trang từ chối truy cập ra khỏi các bản ghi được trích xuất. Nếu thiếu thông tin xác thực đã được ủy quyền, chuyển công việc tới cấu hình thông tin xác thực; nếu chính sách từ chối quyền truy cập, dừng mục tiêu đó và tăng cường lên chủ sở hữu dữ liệu.
Chỉ thu thập dữ liệu công khai hoặc dữ liệu đã được ủy quyền đúng cách, giảm thiểu khối lượng yêu cầu, và bảo vệ bí mật khỏi các prompt, nhật ký và kho lưu trữ. Xử lý trạng thái chính xác cải thiện độ tin cậy chính xác vì nó duy trì quyết định bảo mật thay vì làm mờ nó.
Sử dụng Mã Nhé Khớp Với Quyết Định An Ninh
HTTP 401 có nghĩa là không có xác thực hợp lệ; HTTP 403 có nghĩa là quyền truy cập bị từ chối. Những từ này dễ bị nhầm lẫn, nhưng quy tắc hoạt động thì ổn định: thiết lập danh tính trước, sau đó đánh giá quyền.
Các khách hàng nên xác thực qua các luồng được phê duyệt sau 401 và dừng lại hoặc yêu cầu quyền truy cập sau 403. Các máy chủ nên ghi lại toàn bộ quyết định một cách an toàn, trả về một phản hồi công khai nhất quán, và tránh biến các lỗi quyền thành các lỗi ứng dụng không rõ ràng.
Sẵn sàng xây dựng quy trình dữ liệu quan sát hơn?
Sử dụng các quy tắc xác thực rõ ràng cho trạng thái, danh tính, định tuyến, và nội dung đã hiển thị trước khi một trang vào tập dữ liệu của bạn.
Đăng ký ngay hôm nay và nhận $5 tín dụng miễn phí — không yêu cầu thẻ tín dụng.
Nhận $5 tín dụng của bạn →Câu hỏi thường gặp
Có phải 401 có nghĩa là mật khẩu sai?
Một mã 401 có thể có nghĩa là mật khẩu hoặc một thông tin xác thực khác sai, nhưng nó cũng có thể có nghĩa là thiếu thông tin xác thực, đã hết hạn, bị thu hồi, dành cho một đối tượng khác, hoặc không hợp lệ theo sơ đồ xác thực được công bố.
Có phải 403 có nghĩa là người dùng đã đăng nhập?
Một mã 403 thường có nghĩa là máy chủ biết người gọi và từ chối quyền, nhưng các triển khai cũng có thể sử dụng 403 cho việc từ chối chính sách rộng hơn. Nhật ký máy chủ nên xác nhận nguyên tắc đã nhận diện và quy tắc ủy quyền chính xác.
Có phải mã thông báo đã hết hạn trả về 401 hay 403?
Một mã thông báo đã hết hạn thường trả về 401 vì nó không còn thiết lập xác thực hợp lệ cho yêu cầu. Khách hàng sau đó có thể sử dụng quy trình danh tính được phê duyệt để nhận thông tin xác thực hợp lệ.
Máy chủ có thể trả về 404 thay vì 403 không?
Một máy chủ có thể trả về 404 cho một tài nguyên riêng tư khi tiết lộ sự tồn tại của nó sẽ tiết lộ thông tin nhạy cảm. Chính sách nên được thực hiện một cách có chủ ý, được tài liệu hóa, và được áp dụng nhất quán trên các phương pháp và điểm cuối.
Scraper nên xử lý 401 và 403 như thế nào?
Một scraper nên giữ cả hai phản hồi ra khỏi dữ liệu đã trích xuất. Nó có thể điều chỉnh cấu hình thông tin xác thực đã được ủy quyền sau 401, nhưng nó nên dừng lại sau 403 và tôn trọng quyết định quyền của mục tiêu, điều khoản và luật hiện hành.