403 Forbidden vs 401 Respons HTTP tidak sah

Untuk halaman web yang ada, tetapi untuk yang pengguna yang tidak memiliki hak istimewa yang memadai (mereka tidak login atau bukan milik kelompok pengguna yang sesuai), apa tanggapan HTTP yang benar untuk layanan ini? 401? 403? Sesuatu yang lain Apa yang saya baca pada masing-masing dari mereka sejauh ini tidak begitu jelas tentang perbedaan di antara mereka. Kasus penggunaan apa yang sesuai untuk setiap jawaban?

2117
21 июля '10 в 10:21 2010-07-21 10:21 VirtuosiMedia diatur pada 21 Juli '10 pada 10:21 2010-07-21 10:21
@ 14 jawaban

Penjelasan yang jelas dari Daniel Irvine :

Masalah dengan 401 Kode status HTTP tidak sah untuk kesalahan otentikasi. Dan itu sederhana: untuk otentikasi, bukan untuk otorisasi. Mendapatkan respons 401 adalah server yang memberi tahu Anda: "Anda tidak diautentikasi - baik tidak diautentikasi sama sekali, atau diautentikasi secara tidak benar, tetapi periksa lagi dan coba lagi." Untuk membantu Anda, itu akan selalu menyertakan header WWW-Authenticate, yang menjelaskan cara mengotentikasi.

Ini adalah jawaban yang biasanya dikembalikan oleh server web Anda, dan bukan situs web aplikasi.

Ini juga sangat sementara; server meminta Anda untuk mencoba lagi.

Jadi, untuk otorisasi saya menggunakan 403 jawaban terlarang. itu permanen, terikat pada logika aplikasi saya, dan lebih spesifik dari 401.

Mendapatkan respons 403 adalah server memberi tahu Anda: "Maaf, saya tahu siapa Anda, saya percaya siapa yang Anda katakan, tetapi Anda hanya tidak memiliki izin untuk mengakses sumber ini. Mungkin jika Anda bertanya kepada administrator sistem, Anda akan mendapatkan izin Tapi tolong, jangan khawatirkan saya lagi sampai kesulitan Anda berubah. "

Dengan demikian, 401 Respon Tidak Resmi harus digunakan untuk atau otentikasi buruk, dan respons 403 terlarang harus digunakan setelah ini, ketika pengguna diautentikasi, tetapi tidak memiliki hak untuk melakukan operasi yang diminta pada sumber daya yang diberikan.

Format grafis indah lainnya tentang cara menggunakan kode status http.

3150
04 авг. jawabannya diberikan oleh JPReddy 04 Agustus. 2011-08-04 09:24 '11 pada jam 9:24, 2011-08-04 09:24

Lihat RFC2616 :

401 Tidak Resmi:

Jika permintaan telah menyertakan kredensial otorisasi, maka respons 401 menunjukkan bahwa otorisasi ditolak untuk kredensial ini.

403 Dilarang:

Server mengerti permintaan itu, tetapi menolak untuk mengeksekusinya.

Perbarui

Dari use case Anda, ternyata pengguna tidak diautentikasi. Saya akan mengembalikan 401.


Sunting: RFC2616 sudah usang, lihat RFC7231 dan RFC7235 .

352
21 июля '10 в 10:28 2010-07-21 10:28 jawabannya diberikan Oded 21 Juli '10 pada 10:28 2010-07-21 10:28

Kekurangan lain dari tanggapan adalah bahwa harus dipahami bahwa Otentikasi dan Otorisasi dalam konteks RFC 2616 HANYA milik protokol otentikasi HTTP RFC 2617. Otentikasi menggunakan skema non-RFC 2617 tidak didukung dalam kode status HTTP dan tidak dipertimbangkan ketika memutuskan untuk menggunakan 401 atau 403.

Pendek dan pendek

Tidak sah menunjukkan bahwa klien gagal otentikasi RFC2617 dan server memulai proses otentikasi. Terlarang menunjukkan bahwa klien telah melewati otentikasi RFC2617 dan tidak diotorisasi atau bahwa server tidak mendukung RFC2617 untuk sumber daya yang diminta.

Ini berarti bahwa jika Anda memiliki proses login sendiri dan Anda tidak pernah menggunakan otentikasi HTTP, 403 selalu merupakan jawaban yang tepat, dan 401 seharusnya tidak pernah digunakan.

Detail dan mendalam

Dari RFC2616

10.4.2 401 Tidak Resmi

Permintaan membutuhkan otentikasi pengguna. Jawabannya HARUS menyertakan bidang header WWW-Otentikasi (bagian 14.47) yang berisi permintaan yang berlaku untuk sumber daya yang diminta. Klien MUNGKIN mengu>

dan juga

10.4.4 403 Terlarang Server memahami permintaan tersebut, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diu>

Hal pertama yang perlu diingat adalah bahwa "Otentikasi" dan "Otorisasi" dalam konteks dokumen ini merujuk secara khusus ke protokol otentikasi HTTP dari RFC 2617. Mereka tidak merujuk ke protokol otentikasi apa pun yang mungkin Anda buat . penggunaan halaman login, dll. Saya akan menggunakan "login" untuk merujuk ke otentikasi dan otorisasi selain RFC2617

Jadi perbedaan sebenarnya bukanlah apa masalahnya, atau bahkan jika ada solusinya. Perbedaannya adalah bahwa server mengharapkan klien untuk melakukan selanjutnya.

401 menunjukkan bahwa sumber daya tidak dapat disediakan, tetapi server meminta klien untuk masuk melalui otentikasi HTTP dan mengirim header respons untuk memulai proses. Mungkin ada otorisasi yang akan memungkinkan akses ke sumber daya, mungkin tidak, tetapi mari kita coba dan lihat apa yang terjadi.

403 menunjukkan bahwa sumber daya tidak dapat disediakan, dan untuk pengguna saat ini tidak ada cara untuk menyelesaikan ini melalui RFC2617 dan tidak ada gunanya mencoba. Ini mungkin disebabkan oleh fakta bahwa diketahui bahwa tidak ada tingkat otentikasi yang memadai (misalnya, karena daftar hitam alamat IP), tetapi ini mungkin disebabkan oleh fakta bahwa pengguna telah diautentikasi dan tidak memiliki wewenang. RFC2617 adalah pengguna tunggal, pengguna tunggal, sehingga kasus di mana pengguna mungkin memiliki set kredensial kedua yang dapat diotorisasi dapat diabaikan. Ini tidak menyiratkan atau menyiratkan bahwa halaman login atau protokol otentikasi lain selain RFC2617 dapat atau mungkin tidak membantu - yang berada di luar standar dan definisi RFC2616.


Ubah: RFC2616 sudah ditinggalkan, lihat RFC7231 dan RFC7235 .

266
05 февр. jawabannya diberikan ldrut 05 feb . 2013-02-05 20:14 '13 pada 20:14 2013-02-05 20:14

Sesuai dengan RFC 2616 (HTTP / 1.1), 403 dikirim ketika:

Server mengerti permintaan itu, tetapi menolak untuk mengeksekusinya. Otorisasi tidak akan membantu, dan permintaan TIDAK HARUS diu>

Dengan kata lain, jika klien DAPAT mengakses sumber daya melalui otentikasi, Anda harus mengirim 401.

104
21 июля '10 в 10:26 2010-07-21 10:26 Jawaban diberikan oleh Cumbayah pada 21 Juli '10 pada 10:26 2010-07-21 10:26
DAPATKAN, sumber daya ada? |  |  TIDAK |  |  Ya ay404 Apakah dikonfirmasi (login)?  |  |   TIDAK |  |  Ya  ay  401 Dapatkah mengakses sumber daya (memiliki izin)?(atau: 404) |  |atau 301 TIDAK |  |  Yaredirect vvuntuk masuk 403 OK 200, 301, ...

Cek biasanya dilakukan dengan urutan sebagai berikut:

  • 401 jika login atau sesi tidak selesai
  • 403 jika pengguna tidak memiliki izin untuk mengakses sumber daya
  • 404 jika sumber daya tidak ada

UNAUTHORIZED : kode status (401) yang menunjukkan bahwa permintaan memerlukan otentikasi , yang biasanya berarti bahwa pengguna harus terdaftar (sesi). Pengguna / agen tidak dikenal ke server. Dapat diu>

DILARANG : kode status (403), menunjukkan bahwa server memahami permintaan tersebut, tetapi menolak untuk menjalankannya. Seorang pengguna / agen yang dikenal ke server, tetapi dengan kredensial tidak memadai . Permintaan beru>

TIDAK DITEMUKAN : Kode status (404) yang menunjukkan bahwa sumber daya yang diminta tidak tersedia. Pengguna / agen terkenal, tetapi server tidak melaporkan apa pun tentang sumber daya ini, seolah-olah tidak ada. Pengu>

82
23 февр. Balas diberikan oleh Christophe Roussy pada 23 Februari 2015-02-23 14:00 '15 pada 14:00 2015-02-23 14:00

Jika otentikasi sebagai pengguna lain memberikan akses ke sumber daya yang diminta, maka 401 Tidak Sah harus dikembalikan. 403 Biasanya dilarang untuk digunakan ketika akses ke sumber daya ditolak untuk semua atau terbatas pada jaringan tertentu atau hanya diizinkan melalui SSL, terlepas dari apakah itu tidak terkait dengan otentikasi.

Dari RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Otentikasi):

3.1. 401 Tidak Resmi

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan tidak berlaku, karena tidak memiliki data otentikasi yang dapat diandalkan untuk sumber daya target. Server sumber HARUS mengirim bidang header WWW-Otentikasi (bagian 4.4) yang berisi setidaknya satu panggilan yang berlaku untuk sumber daya target. Jika permintaan menyertakan kredensial otentikasi, maka respons 401 menunjukkan bahwa izin telah ditolak untuk Otorisasi tersebut . Klien MUNGKIN mengu>

Dan ini dari RFC 2616:

10.4.4 403 Dilarang

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.
Otorisasi tidak akan membantu , dan permintaan TIDAK HARUS diu> Jika metode permintaan itu bukan KEPALA, dan server ingin membuat permintaan itu tidak dieksekusi, itu HARUS menggambarkan alasan penolakan dalam badan hukum. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404
(Tidak ditemukan).

Sunting: RFC 7231 (Protokol Transfer Hiperteks (HTTP / 1.1): Semantik dan Konten) mengubah nilai 403:

6.5.3. 403 Dilarang

Kode status 403 (Terlarang) menunjukkan bahwa server memahami permintaan tersebut, tetapi menolak untuk mengesahkannya. Server yang ingin mengumumkan kepada publik mengapa permintaan itu ditolak dapat menggambarkan alasan ini dalam muatan respons (jika ada).

Jika kredensial diberikan dalam permintaan, permintaan dianggap tidak cukup oleh server untuk memberikan akses. Pe>
TIDAK HARUS mengu>
kekuatan Klien MUNGKIN mengu> Namun, permintaan tersebut dapat ditolak karena alasan yang tidak terkait dengan otoritas.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari sumber daya target yang dilarang, MUNGKIN merespons dengan kode status 404 (tidak ditemukan).

Dengan demikian, 403 sekarang dapat berarti apa saja. Memberikan kredensial baru dapat membantu ... atau mungkin juga tidak.

38
27 февр. jawabannya diberikan oleh Erwan Legrand pada 27 Februari. 2013-02-27 12:44 '13 pada 12:44 2013-02-27 12:44

Ini adalah pertanyaan yang lebih tua, tetapi satu opsi yang tidak pernah diajukan adalah mengembalikan 404. Dari sudut pandang keamanan, respons suara tertinggi menderita dari potensi kerentanan kebocoran informasi . Katakan, misalnya, bahwa halaman web yang dilindungi yang dimaksud adalah halaman administrasi sistem atau, paling sering, catatan dalam sistem yang tidak dapat diakses oleh pengguna. Idealnya, Anda tidak ingin pengguna jahat tahu bahwa ada halaman / posting di sana, belum lagi bahwa mereka tidak memiliki akses. Ketika saya membuat sesuatu seperti ini, saya akan mencoba untuk menulis permintaan yang tidak diautentikasi / tidak sah di log internal, tetapi saya mengembalikan 404.

OWASP memiliki informasi tambahan tentang bagaimana penyerang dapat menggunakan jenis informasi ini sebagai bagian dari serangan.

23
25 дек. Balas diberikan oleh Patrick White 25 Des 2014-12-25 12:09 '14 pukul 12:09 2014-12-25 12:09

Pertanyaan ini ditanyakan beberapa waktu lalu, tetapi orang-orang berpikir untuk melanjutkan.

Bagian 6.5.3 dalam proyek ini (oleh Fielding dan Reschke) memberikan kode status 403, yang sedikit berbeda dari nilai yang dijelaskan dalam RFC 2616 .

Ini mencerminkan apa yang terjadi dalam skema otentikasi dan otorisasi yang digunakan oleh sejumlah server dan kerangka kerja web populer.

Saya menekankan bahwa sedikit, yang, menurut pendapat saya, adalah yang paling luar biasa.

6.5.3. 403 Dilarang

Kode status 403 (Terlarang) menunjukkan bahwa server memahami permintaan tersebut, tetapi menolak untuk mengesahkannya. Server yang ingin mengumumkan kepada publik mengapa permintaan itu ditolak dapat menggambarkan alasan ini dalam muatan respons (jika ada).

Jika kredensial diberikan dalam permintaan, server menganggapnya tidak cukup untuk menyediakan akses. Klien TIDAK HARUS mengu> Klien MUNGKIN mengu> Namun, permintaan tersebut dapat ditolak karena alasan selain kredensial.

Server asal yang ingin menyembunyikan keberadaan saat ini dari target sumber daya terlarang dapat sebaliknya merespons dengan kode status 404 (tidak ditemukan).

Apa pun perjanjian yang Anda gunakan, penting untuk memastikan keseragaman di situs web / API Anda.

20
22 мая '14 в 13:54 2014-05-22 13:54 Jawaban diberikan oleh Dave Watts 22 Mei '14 pukul 13:54 2014-05-22 13:54

mereka tidak masuk atau tidak termasuk kelompok pengguna yang sesuai

Anda telah menyatakan dua kasus berbeda; Setiap kasus harus memiliki jawaban yang berbeda:

  1. Jika mereka tidak masuk sama sekali, Anda harus mengembalikan 401 Tidak Sah
  2. Jika mereka masuk, tetapi bukan milik kelompok pengguna yang sesuai, Anda harus mengembalikan 403 Forbidden

Komentar RFC berdasarkan komentar yang diterima untuk jawaban ini:

Jika pengguna tidak masuk, mereka tidak diautentikasi, yang setara dengan HTTP yang 401 dan menyesatkan sebagai tidak valid dalam RFC. Sejak bagian 10.4.2 menentukan 401 Tidak Resmi :

"Permintaan membutuhkan otentikasi pengguna".

Jika Anda tidak lulus tes, 401 adalah jawaban yang benar. Namun, jika Anda tidak sah, dalam arti semantik yang benar, 403 adalah jawaban yang benar.

9
01 окт. jawabannya diberikan Zaid Masud 01 Oktober. 2012-10-01 17:34 '12 pada 17:34 2012-10-01 17:34

Tl; DR

  • 401: kegagalan otentikasi
  • 403: kegagalan yang TIDAK dilakukan dengan otentikasi

Contoh-contoh praktis

Jika apache memerlukan otentikasi (via .htaccess ), dan Anda mengklik " Cancel , itu akan merespons dengan 401 Authorization Required

Jika nginx menemukan file tetapi tidak memiliki izin (pengguna / grup) untuk membaca / mengaksesnya, itu akan membalas 403 Forbidden

RFC (2616, bagian 10)

401 Tidak Resmi (10.4.2)

Artinya 1: Diperlukan Otentikasi

Permintaan membutuhkan otentikasi pengguna ....

Artinya 2: tidak cukup otentikasi

... Jika permintaan telah menyertakan kredensial otorisasi, maka respons 401 menunjukkan bahwa otorisasi ditolak untuk kredensial ini ....

403 Forbidden (10.4.4)

Artinya: tidak terkait dengan otentikasi

... Otorisasi tidak akan membantu ...

Lebih detail:

  • Server mengerti permintaan itu, tetapi menolak untuk mengeksekusinya.

  • HARUS menjelaskan alasan penolakan dalam suatu badan hukum.

  • Sebagai gantinya, Anda dapat menggunakan kode status 404 (tidak ditemukan)

    (Jika server ingin menyimpan informasi ini dari klien)

9
25 февр. balasan yang diberikan oleh Imamat 25 Februari 2015-02-25 12:03 '15 pada 12:03 2015-02-25 12:03

Saya pikir penting untuk diingat bahwa untuk browser 401 itu memulai dialog otentikasi bagi pengguna untuk memasukkan kredensial baru, dan 403 tidak. Browser percaya bahwa jika 401 dikembalikan, pengguna harus mengautentikasi u>

Berikut adalah beberapa kasus sesuai dengan logika ini, ketika kesalahan dikembalikan dari otentikasi atau otorisasi, menyoroti frasa penting.

  • Sumber daya membutuhkan otentikasi, tetapi tidak ada kredensial yang disediakan .

401 : Klien harus memberikan kredensial.

  • Kredensial yang ditentukan memiliki format yang tidak valid .

400 : bahwa bukan 401 atau 403, karena kesalahan sintaks harus selalu menghasilkan 400.

  • Kredensial yang ditentukan merujuk ke pengguna yang tidak ada .

401 : Klien harus memberikan kredensial yang valid.

  • Kredensial yang ditentukan tidak valid, tetapi mengindikasikan pengguna yang valid (atau tidak menentukan pengguna jika pengguna yang ditentukan tidak diperlukan).

401 : Sekali lagi, klien harus memberikan kredensial yang valid.

  • Kredensial yang ditentukan telah kedaluwarsa .

401 : Ini praktis sama dengan kredensial yang salah secara keseluruhan, sehingga klien harus memberikan kredensial yang valid.

  • Kredensial ini sepenuhnya valid, tetapi mereka tidak cukup untuk sumber daya tertentu, meskipun mungkin kredensial dengan hak yang lebih luas dapat melakukannya.

403. Menentukan kredensial yang valid tidak akan memberikan akses ke sumber daya, karena kredensial saat ini sudah valid, tetapi hanya tidak memiliki izin.

  • Sumber daya yang ditentukan tidak tersedia terlepas dari kredensial.

403. Itu tidak tergantung pada kredensial, jadi menentukan kredensial yang valid tidak dapat membantu.

  • Kredensial ini sepenuhnya valid, tetapi klien tertentu diblokir agar tidak menggunakannya.

403. Jika klien diblokir, menentukan kredensial baru tidak akan mengubah apa pun.

3
03 июня '18 в 2:34 2018-06-03 02:34 dijawab oleh Grant Gryczan pada 03 Juni '18 pada 2:34 ; 2018-06-03 02:34

Itu lebih mudah di kepala saya daripada di tempat lain, oleh karena itu:

401: untuk ini Anda perlu autentikasi dasar HTTP.

403: Anda tidak dapat melihat ini, dan autentikasi dasar HTTP tidak akan membantu.

Jika pengguna hanya perlu masuk menggunakan formulir login standar di situs Anda, 401 tidak akan cocok karena khusus untuk autentikasi dasar HTTP.

Saya tidak merekomendasikan menggunakan 403 untuk menolak akses ke hal-hal seperti /includes , karena sehubungan dengan Internet sumber daya ini tidak ada sama sekali dan oleh karena itu harus ada 404.

Ini meninggalkan 403 sebagai "Anda harus masuk."

Dengan kata lain, 403 berarti bahwa "sumber daya ini memerlukan beberapa bentuk auth, selain autentikasi dasar HTTP".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

2
23 сент. jawabannya diberikan Vladimir Kornea 23 September . 2017-09-23 15:33 '17 pada 15:33 2017-09-23 15:33

Mengingat RFC terbaru tentang masalah ini ( 7231 dan 7235 ), preseden tampaknya cukup dimengerti (cetak miring ditambahkan):

  • 401 - untuk yang tidak diautentikasi ("tidak ada otentikasi yang valid tidak ada"); yaitu "Aku tidak tahu siapa kamu, atau aku tidak percaya bahwa kamu adalah dirimu sendiri."

401 Tidak Resmi

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan tersebut tidak diterapkan karena tidak memiliki kredensial yang valid untuk sumber daya target. Server menghasilkan jawaban 401 HARUS mengirim bidang header WWW-Otentikasi (bagian 4.1) yang mengandung setidaknya satu masalah yang berlaku untuk sumber daya target.