403 Forbidden vs 401 Respons HTTP tidak sah


2785

Untuk halaman web yang ada, tetapi yang pengguna tidak memiliki hak istimewa yang memadai (mereka tidak masuk atau tidak termasuk kelompok pengguna yang tepat), apa tanggapan HTTP yang tepat untuk dilayani?

401 Unauthorized?
403 Forbidden?
Sesuatu yang lain

Apa yang saya baca pada masing-masing sejauh ini tidak begitu jelas tentang perbedaan antara keduanya. Kasus penggunaan apa yang sesuai untuk setiap respons?


358
401 'Tidak Sah' harus 401 'Tidak Diauthentikasi', masalah diselesaikan!
Christophe Roussy

47
Saya tidak ingat berapa kali saya dan kolega saya kembali ke stackoverflow untuk pertanyaan ini. Mungkin standar HTTP harus mempertimbangkan memodifikasi nama atau deskripsi untuk 401 dan 403.
neurite

Bahkan, saya mendapatkan versi yang berbeda dari kesalahan ini. seperti "os_authType adalah 'any' dan cookie yang tidak valid dikirim". Jadi tidak dapat menemukan cara untuk menyelesaikannya. Googled banyak waktu, punya alasan tetapi tidak mendapatkan solusi.
Sandeep Anand

@Qwerty no, RFC7231 baru menggantikan RFC2616. 403 memiliki arti yang berbeda sekarang.
Tulang ikan

1
@fishbone Anda juga tidak mencatat bahwa kode status 401 telah dihapus dari RFC: D
Barkermn01

Jawaban:


4115

Penjelasan yang jelas dari Daniel Irvine :

Ada masalah dengan 401 Tidak Resmi , kode status HTTP untuk kesalahan otentikasi. Dan hanya itu: itu untuk otentikasi, bukan otorisasi. Menerima respons 401 adalah server memberi tahu Anda, "Anda tidak diautentikasi - baik tidak diautentikasi sama sekali atau diautentikasi secara tidak benar - tetapi harap diautentikasi ulang dan coba lagi." Untuk membantu Anda, itu akan selalu menyertakan header WWW-Otentikasi yang menjelaskan cara mengotentikasi.

Ini adalah respons yang umumnya dikembalikan oleh server web Anda, bukan aplikasi web Anda.

Itu juga sesuatu yang sangat sementara; server meminta Anda untuk mencoba lagi.

Jadi, untuk otorisasi saya menggunakan respons Terlarang 403 . Ini permanen, ini terkait dengan logika aplikasi saya, dan ini merupakan respons yang lebih konkret daripada 401.

Menerima respons 403 adalah server memberi tahu Anda, “Maaf. Saya tahu siapa Anda - saya percaya siapa yang Anda katakan - tetapi Anda tidak memiliki izin untuk mengakses sumber ini. Mungkin jika Anda bertanya kepada administrator sistem dengan baik, Anda akan mendapatkan izin. Tapi tolong jangan ganggu aku lagi sampai kesulitanmu berubah. ”

Singkatnya, respons 401 Tidak Sah harus digunakan untuk otentikasi yang hilang atau buruk, dan respons Terlarang 403 harus digunakan setelahnya, ketika pengguna diautentikasi tetapi tidak berwenang untuk melakukan operasi yang diminta pada sumber daya yang diberikan.

Format gambar bagus lainnya tentang bagaimana kode status http harus digunakan.

masukkan deskripsi gambar di sini


43
Pesan IIS 403 default adalah "Ini adalah kesalahan umum 403 dan berarti pengguna yang diautentikasi tidak berwenang untuk melihat halaman", yang tampaknya setuju.
Ben Challenor

333
@JPReddy Jawaban Anda benar. Namun, saya berharap bahwa 401 dinamai "Tidak Diauthentikasi" dan 403 dinamai "Tidak Diotorisasi". Sangat membingungkan bahwa 401, yang berkaitan dengan Otentikasi, memiliki format teks yang menyertai "Tidak Diotorisasi" .... Kecuali saya tidak pandai dalam Bahasa Inggris (yang kemungkinan besar).
p.matsinopoulos

64
@ZaidMasud, menurut RFC interpretasi ini tidak benar. Jawaban Cumbayah benar. 401 berarti "Anda kehilangan otorisasi yang tepat". Ini menyiratkan "jika Anda mau, Anda mungkin mencoba untuk mengotentikasi diri Anda" Jadi, baik klien yang tidak mengotentikasi dirinya sendiri dengan benar dan klien yang diautentikasi dengan benar kehilangan otorisasi akan mendapatkan 401. 403 berarti "Saya tidak akan menjawab ini, siapa pun Anda". RFC menyatakan dengan jelas bahwa "otorisasi tidak akan membantu" dalam kasus 403.
Davide R.

84
401 adalah kesalahan Otentikasi, 403 adalah kesalahan Otorisasi. Sederhana seperti itu.
Shahriyar Imanov

30
Anda meninggalkan "Yah, itulah pandangan saya tentang itu :)" ketika menyalin dari posting blognya dan sayangnya pandangannya salah. Seperti yang orang lain nyatakan 403 berarti Anda tidak dapat mengakses sumber daya terlepas dari siapa Anda diautentikasi. Saya biasanya menggunakan kode status ini untuk sumber daya yang dikunci oleh rentang alamat IP atau file di webroot saya yang saya tidak ingin akses langsung ke (yaitu skrip harus melayani mereka).
Kyle

403

Lihat RFC2616 :

401 Tidak Resmi:

Jika permintaan sudah menyertakan kredensial Otorisasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut.

403 Dilarang:

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.

Memperbarui

Dari kasus penggunaan Anda, tampaknya pengguna tidak diautentikasi. Saya akan kembali 401.


Sunting: RFC2616 sudah usang, lihat RFC7231 dan RFC7235 .


21
Terima kasih, itu membantu menjelaskannya untuk saya. Saya menggunakan keduanya - 401 untuk pengguna yang tidak diautentikasi, 403 untuk pengguna yang diautentikasi dengan izin yang tidak mencukupi.
VirtuosiMedia

52
Saya tidak mengundurkan diri tetapi saya menemukan jawaban ini cukup menyesatkan. 403 forbidden lebih tepat digunakan dalam konten yang tidak akan pernah dilayani (seperti file .config di asp.net). baik itu atau 404. Iho, itu tidak pantas untuk mengembalikan 403 untuk sesuatu yang dapat diakses tetapi Anda hanya tidak memiliki kredensial yang tepat. solusi saya adalah memberikan akses ditolak pesan dengan cara mengubah kredensial. itu atau 401.
Mel

27
"Respons HARUS menyertakan bidang header WWW-Otentikasi (bagian 14.47) yang berisi tantangan yang berlaku untuk sumber daya yang diminta." Tampaknya jika Anda tidak ingin menggunakan otentikasi gaya HTTP, kode respons 401 tidak sesuai.
Brilliand

8
Saya akan mendukung Billiand di sini. Pernyataan itu adalah "Jika permintaan sudah menyertakan kredensial Otorisasi". Itu berarti jika ini merupakan respons dari permintaan yang memberikan kredensial (mis. Respons dari upaya Otentikasi RFC2617). Ini pada dasarnya memungkinkan server untuk mengatakan, "Pasangan akun / kata sandi salah, coba lagi". Dalam pertanyaan yang diajukan, pengguna mungkin diautentikasi tetapi tidak diotorisasi. 401 tidak pernah merupakan respons yang tepat untuk situasi tersebut.
ldrut

6
Brilliand benar, 401 hanya sesuai untuk Otentikasi HTTP.
Juampi

296

Sesuatu yang tidak dijawab oleh jawaban lain adalah harus dipahami bahwa Otentikasi dan Otorisasi dalam konteks RFC 2616 merujuk HANYA pada protokol HTTP Authentication dari RFC 2617. Otentikasi dengan skema di luar RFC2617 tidak didukung dalam kode status HTTP dan tidak dianggap sebagai kode saat memutuskan apakah akan menggunakan 401 atau 403.

Singkat dan Terse

Tidak sah menunjukkan bahwa klien tidak dikonfirmasi dengan RFC2617 dan server memulai proses otentikasi. Forbidden menunjukkan bahwa klien diautentikasi RFC2617 dan tidak memiliki otorisasi atau bahwa server tidak mendukung RFC2617 untuk sumber daya yang diminta.

Berarti jika Anda memiliki proses masuk roll-Anda-sendiri dan tidak pernah menggunakan Otentikasi HTTP, 403 selalu merupakan respons yang tepat dan 401 tidak boleh digunakan.

Detail dan Mendalam

Dari RFC2616

10.4.2 401 Tidak Resmi

Permintaan membutuhkan otentikasi pengguna. Respons HARUS menyertakan bidang tajuk WWW-Otentikasi (bagian 14.47) yang berisi tantangan yang berlaku untuk sumber daya yang diminta. Klien MUNGKIN mengulangi permintaan dengan bidang tajuk Otorisasi yang sesuai (bagian 14.8).

dan

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

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

Jadi perbedaan sebenarnya bukanlah apa masalahnya atau bahkan jika ada solusinya. Perbedaannya adalah apa yang server harapkan untuk dilakukan klien selanjutnya.

401 menunjukkan bahwa sumber daya tidak dapat disediakan, tetapi server MEMINTA bahwa klien login melalui Otentikasi HTTP dan telah mengirim header balasan untuk memulai proses. Mungkin ada otorisasi yang akan mengizinkan akses ke sumber daya, mungkin tidak ada, tapi mari kita coba dan lihat apa yang terjadi.

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


Sunting: RFC2616 sudah usang, lihat RFC7231 dan RFC7235 .


7
Jadi apa yang harus kita lakukan ketika pengguna meminta halaman yang memerlukan otentikasi non-http? Kirim kode status 403?
marcovtwout

2
Ini adalah jawaban yang menjawab pertanyaan saya tentang perbedaan.
Patrick

9
Ini penting: "jika Anda memiliki proses login roll-your-own Anda sendiri dan tidak pernah menggunakan Otentikasi HTTP, 403 selalu merupakan respons yang tepat dan 401 tidak boleh digunakan."
ggg

1
@marcovtwout Kirim 302 ke halaman login Anda, atau 403 berisi badan dengan informasi cara masuk?
Alex

4
Tidakkah RFC7235 menyediakan tantangan "roll-your-own" atau auth? Mengapa alur masuk aplikasi saya tidak dapat menyajikan tantangannya dalam bentuk WWW-Authenticatetajuk? Sekalipun peramban tidak mendukungnya, aplikasi Bereaksi saya dapat ...
jchook

127
  + -----------------------
  | ADA SUMBER DAYA? (jika pribadi sering diperiksa SETELAH pemeriksaan auth)
  + -----------------------
    | |
 TIDAK | v YA
    v + -----------------------
   404 | APAKAH SUDAH MASUK ? (dikonfirmasi, alias memiliki sesi atau cookie JWT)
   atau + -----------------------
   401 | |
   403 TIDAK | | IYA
   3xx vv
              401 + -----------------------
       (404 tidak terungkap) | BISAKAH AKSES SUMBERDAYA? (izin, resmi, ...)
              atau + -----------------------
             redirect | |
             untuk login NO | | IYA
                               | |
                               ay
                               403 OK 200, redirect, ...
                      (atau 404: tidak ada pengungkapan)
                      (atau 404: sumber daya tidak ada jika pribadi)
                      (atau 3xx: pengalihan)

Cek biasanya dilakukan dalam urutan ini:

  • 404 jika sumber daya bersifat publik dan tidak ada atau pengalihan 3xx
  • JIKA TIDAK:
  • 401 jika tidak masuk atau sesi kedaluwarsa
  • 403 jika pengguna tidak memiliki izin untuk mengakses sumber daya (file, json, ...)
  • 404 jika sumber daya tidak ada atau tidak mau mengungkapkan apa pun, atau pengalihan 3xx

TIDAK DIKENAL : Kode status (401) yang menunjukkan bahwa permintaan memerlukan otentikasi , biasanya ini berarti pengguna harus masuk (sesi). Pengguna / agen tidak dikenal oleh server. Dapat diulangi dengan kredensial lain. CATATAN: Ini membingungkan karena ini seharusnya dinamai 'tidak terauthentikasi' alih-alih 'tidak sah'. Ini juga dapat terjadi setelah masuk jika sesi berakhir. Kasus khusus: Dapat digunakan sebagai ganti 404 untuk menghindari mengungkapkan ada atau tidak adanya sumber daya (kredit @gingerCodeNinja)

DILARANG : Kode status (403) yang mengindikasikan server memahami permintaan tersebut tetapi menolak untuk memenuhinya. Pengguna / agen yang dikenal oleh server tetapi tidak memiliki kredensial yang memadai . Permintaan berulang tidak akan berfungsi, kecuali kredensial berubah, yang sangat tidak mungkin dalam rentang waktu singkat. Kasus khusus: Dapat digunakan sebagai ganti 404 untuk menghindari mengungkapkan ada atau tidak adanya sumber daya (kredit @gingerCodeNinja)

TIDAK DITEMUKAN : Kode status (404) yang menunjukkan bahwa sumber daya yang diminta tidak tersedia. Pengguna / agen diketahui tetapi server tidak akan mengungkapkan apa pun tentang sumber daya, apakah seolah-olah tidak ada. Mengulang tidak akan berhasil. Ini adalah penggunaan khusus 404 (github melakukannya misalnya).

Seperti yang disebutkan oleh @ChrisH ada beberapa opsi untuk pengalihan 3xx (301, 302, 303, 307 atau tidak mengarahkan sama sekali dan menggunakan 401):


Misalnya saya sudah masuk dan saya bisa mengakses halaman tetapi itu tidak mengizinkan saya. Kode status mana yang akan kembali?
barteloma

@bookmarker Loggin in disebut otentikasi, yang merupakan langkah pertama. Jadi, jika Anda tidak memiliki izin setelah masuk, Anda akan mendapatkan 403 Forbidden (kredensial yang tidak memadai berarti Anda tidak memiliki cukup izin).
Christophe Roussy

3
Penjelasan yang jelas dan sederhana. Apa yang saya butuhkan.
Estevez

jika pengguna tidak masuk atau masuk tetapi tidak memiliki izin, dan konten tidak ada di lokasi, kadang-kadang Anda mungkin ingin mengembalikan 401/403 bukan 404, sehingga Anda tidak mengungkapkan apa yang ada atau tidak ada di sana jika pengguna tidak diautentikasi dan login. Hanya mengetahui ada sesuatu dapat mengisyaratkan sesuatu atau merusak NDA. Jadi kadang-kadang bagian 404 dari diagram ini harus dipindahkan saat login / diautentikasi.
gingerCodeNinja

1
@MattKocaj mencatat bahwa no revealkadangkala dapat dideteksi melalui perbedaan waktu yang halus dan tidak boleh dilihat sebagai fitur keamanan, itu mungkin hanya memperlambat penyerang atau membantu sedikit dengan privasi.
Christophe Roussy

113

Menurut RFC 2616 (HTTP / 1.1) 403 dikirim ketika:

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang. Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada publik mengapa permintaan itu belum dipenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya

Dengan kata lain, jika klien BISA mendapatkan akses ke sumber daya dengan mengotentikasi, 401 harus dikirim.


5
Dan jika tidak jelas apakah mereka dapat mengakses atau tidak? Katakanlah saya memiliki 3 level pengguna - Publik, Anggota, dan Anggota Premium. Asumsikan halaman tersebut hanya untuk Anggota Premium. Pengguna publik pada dasarnya tidak diauthentikasi dan bisa berada di Anggota atau Anggota Premium ketika mereka masuk. Untuk tingkat pengguna Anggota, 403 akan tampak sesuai. Untuk Anggota Premium, 401. Namun, apa yang Anda layani Publik?
VirtuosiMedia

27
imho, ini adalah jawaban yang paling akurat. itu tergantung pada aplikasi tetapi umumnya, jika pengguna yang diautentikasi tidak memiliki hak yang memadai pada sumber daya, Anda mungkin ingin memberikan cara untuk mengubah kredensial atau mengirim 401. Saya pikir 403 paling cocok untuk konten yang tidak pernah dilayani. Di asp.net ini berarti file web.config * .resx dll. Karena apa pun pengguna yang login, file-file ini TIDAK AKAN PERNAH dilayani sehingga tidak ada gunanya mencoba lagi.
Mel

6
+1, tapi +1 tidak pasti. Kesimpulan logisnya adalah bahwa 403 tidak boleh dikembalikan karena 401 atau 404 akan menjadi respons yang lebih baik.
CurtainDog

12
@Mel Saya pikir file yang tidak boleh diakses oleh klien harus 404. Ini file yang internal ke sistem; luar seharusnya tidak tahu itu ada. Dengan mengembalikan 403 Anda membiarkan klien tahu itu ada, tidak perlu memberikan informasi itu kepada peretas. Spesifikasi untuk 403 mengatakanAn origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
Juan Mendes

3
Sementara ini bagi saya sepertinya ini mungkin interpretasi yang akurat dari RFC 2616 lama, perhatikan bahwa RFC 7231 mendefinisikan semantik dari 403 secara berbeda , dan pada kenyataannya secara eksplisit menyatakan bahwa "Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda." Jadi, sementara jawaban ini akurat pada 2010, itu sepenuhnya salah hari ini, karena makna kode status telah ditulis ulang di bawah kaki kita. (Anehnya, Perubahan dari lampiran RFC 2616 tidak mengakui perubahan!)
Mark Amery

46

Dengan asumsi otentikasi HTTP ( WWW-Otentikasi dan header Otorisasi ) sedang digunakan , jika otentikasi sebagai pengguna lain akan memberikan akses ke sumber daya yang diminta, maka 401 Tidak Sah harus dikembalikan.

403 Forbidden digunakan ketika akses ke sumber daya dilarang untuk semua orang atau terbatas pada jaringan tertentu atau hanya diizinkan melalui SSL, apa pun asalkan tidak ada hubungannya dengan otentikasi HTTP.

Jika otentikasi HTTP tidak digunakan dan layanan skema otentikasi berbasis cookie seperti norma saat ini, maka 403 atau 404 harus dikembalikan.

Mengenai 401, ini dari RFC 7235 (Protokol Transfer Hiperteks (HTTP / 1.1): Otentikasi):

3.1. 401 Tidak Resmi

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan belum diterapkan karena tidak memiliki kredensial otentikasi yang valid untuk sumber daya target. Server asal HARUS mengirim bidang header WWW-Otentikasi (Bagian 4.4) yang mengandung setidaknya satu tantangan yang berlaku untuk sumber daya target. Jika permintaan menyertakan kredensial autentikasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut. Klien MUNGKIN mengulangi permintaan dengan bidang header Otorisasi baru atau yang diganti (Bagian 4.1). Jika respons 401 berisi tantangan yang sama dengan respons sebelumnya, dan agen pengguna telah mencoba otentikasi setidaknya satu kali, maka agen pengguna HARUS menyajikan representasi terlampir kepada pengguna, karena biasanya berisi informasi diagnostik yang relevan.

Semantik 403 (dan 404) telah berubah seiring waktu. Ini dari tahun 1999 (RFC 2616):

10.4.4 403 Dilarang

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.
Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang.
Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada
publik mengapa permintaan itu belum dipenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404
(Tidak Ditemukan) dapat digunakan sebagai gantinya.

Pada 2014 RFC 7231 (Protokol Transfer Hiperteks (HTTP / 1.1): Semantik dan Konten) mengubah arti 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 dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada).

Jika kredensial otentikasi diberikan dalam permintaan,
server menganggapnya tidak cukup untuk memberikan akses. Klien
TIDAK HARUS mengulangi permintaan dengan
kredensial yang sama . Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda. Namun, permintaan mungkin dilarang karena alasan yang
tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari
sumber daya target terlarang MUNGKIN merespons dengan kode status
404 (Tidak Ditemukan).

Jadi, 403 (atau 404) sekarang mungkin berarti tentang apa pun. Memberikan kredensial baru mungkin membantu ... atau mungkin juga tidak.

Saya percaya alasan mengapa hal ini berubah adalah RFC 2616 diasumsikan otentikasi HTTP akan digunakan ketika dalam praktiknya aplikasi Web saat ini membangun skema otentikasi khusus menggunakan misalnya formulir dan cookie.


2
Ini menarik. Berdasarkan RFC 7231 dan RFC 7235, saya tidak melihat perbedaan yang jelas antara 401 dan 403
Brian

2
403 berarti "Saya mengenal Anda tetapi Anda tidak dapat melihat sumber ini." Tidak ada alasan untuk kebingungan.
Michael Blackburn

"Jika permintaan menyertakan kredensial otentikasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial itu. Klien MUNGKIN mengulangi permintaan dengan bidang header Otorisasi baru atau diganti (Bagian 4.1)." Namun, kemudian "4.2. Bidang tajuk 'Otorisasi' memungkinkan agen pengguna untuk mengotentikasi dirinya dengan server asal". Sepertinya di RFC7235 mereka menggunakan istilah "otorisasi" seperti itu "otentikasi". Dalam hal ini, mungkin terlihat bahwa pengguna yang diautentikasi tetapi tidak diotorisasi tidak boleh mendapatkan 401, melainkan 403
arcuri82

29

Ini adalah pertanyaan yang lebih tua, tetapi satu opsi yang tidak pernah benar-benar diajukan adalah mengembalikan 404. Dari perspektif keamanan, jawaban dengan suara terbanyak menderita dari potensi kerentanan kebocoran informasi . Katakan, misalnya, bahwa halaman web aman yang dimaksud adalah halaman admin sistem, atau mungkin lebih umum, adalah catatan dalam sistem yang tidak dapat diakses oleh pengguna. Idealnya Anda tidak ingin pengguna jahat tahu bahwa ada halaman / catatan di sana, apalagi mereka tidak memiliki akses. Ketika saya sedang membangun sesuatu seperti ini, saya akan mencoba untuk mencatat permintaan yang tidak diautentikasi / tidak sah dalam log internal, tetapi mengembalikan 404.

OWASP memiliki beberapa informasi lebih lanjut tentang bagaimana penyerang dapat menggunakan informasi jenis ini sebagai bagian dari serangan.


3
Penggunaan 404 telah disebutkan dalam jawaban sebelumnya. Anda pada titik re: kebocoran informasi dan ini harus menjadi pertimbangan penting bagi siapa pun yang menggulirkan skema otentikasi / otorisasi mereka sendiri. +1 untuk menyebutkan OWASP.
Dave Watts

Ironisnya, tautan OWASP sekarang menuju ke halaman 404. Saya menemukan sesuatu yang serupa (saya pikir) di owasp.org/index.php/…
anned20

Terima kasih untuk kepala, saya memperbaruinya!
Patrick White

Tergantung pada API dan bagaimana akses diberikan. Tapi "bocor" bukan masalah jika ia mengembalikan 401 untuk nama pengguna / kata sandi sama dengan formulir web?
James

26
  • 401 Tidak Resmi : Saya tidak tahu siapa Anda. Ini kesalahan otentikasi.
  • 403 Forbidden : Saya tahu siapa Anda, tetapi Anda tidak memiliki izin untuk mengakses sumber ini. Ini adalah kesalahan otorisasi.

Tidak yakin secara khusus "selalu" berarti pengirimnya tidak dikenal. Apa pun yang mereka minta tidak diotorisasi.
James

22

Pertanyaan ini diajukan beberapa waktu yang lalu, tetapi pemikiran orang-orang terus berjalan.

Bagian 6.5.3 dalam konsep ini (ditulis oleh Fielding dan Reschke) memberikan kode status 403 arti yang sedikit berbeda dengan yang didokumentasikan dalam RFC 2616 .

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

Saya telah menekankan sedikit yang menurut saya paling menonjol.

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 dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada).

Jika kredensial otentikasi diberikan dalam permintaan, server menganggapnya tidak cukup untuk memberikan akses. Klien TIDAK HARUS mengulangi permintaan dengan kredensial yang sama. Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda. Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari sumber daya target terlarang MUNGKIN merespons dengan kode status 404 (Tidak Ditemukan).

Apa pun konvensi yang Anda gunakan, yang penting adalah memberikan keseragaman di seluruh situs / API Anda.


2
Draf disetujui dan sekarang RFC 7231.
Vebjorn Ljosa

13

TL; DR

  • 401: Penolakan yang berkaitan dengan otentikasi
  • 403: Penolakan yang tidak ada hubungannya dengan otentikasi

Contoh Praktis

Jika apache memerlukan otentikasi (via .htaccess), dan Anda menekan Cancel, itu akan merespons dengan a401 Authorization Required

Jika nginx menemukan file, tetapi tidak memiliki hak akses (pengguna / grup) untuk membaca / mengaksesnya, ia akan merespons403 Forbidden

RFC (2616 Bagian 10)

401 Tidak Resmi (10.4.2)

Artinya 1: Perlu diautentikasi

Permintaan membutuhkan otentikasi pengguna. ...

Artinya 2: Otentikasi tidak cukup

... Jika permintaan sudah menyertakan kredensial Otorisasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut. ...

403 Forbidden (10.4.4)

Artinya: Tidak terkait dengan otentikasi

... Otorisasi tidak akan membantu ...

Keterangan lebih lanjut:

  • Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.

  • HARUS menjelaskan alasan penolakan dalam entitas

  • Kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya

    (Jika server ingin menyimpan informasi ini dari klien)


11

mereka tidak masuk atau tidak termasuk kelompok pengguna yang tepat

Anda telah menyatakan dua kasus berbeda; setiap kasus harus memiliki respons 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 tepat, Anda harus mengembalikan 403 Forbidden

Catatan tentang RFC berdasarkan komentar yang diterima untuk jawaban ini:

Jika pengguna tidak login mereka tidak diautentikasi, HTTP setara yang 401 dan menyesatkan disebut Tidak Diotorisasi dalam RFC. Seperti bagian 10.4.2 menyatakan untuk 401 Tidak Sah :

"Permintaan tersebut membutuhkan otentikasi pengguna ."

Jika Anda tidak diauthentikasi, 401 adalah respons yang benar. Namun jika Anda tidak sah, dalam arti semantik yang benar, 403 adalah respons yang benar.


5
Ini tidak benar. Lihat RFC dan jawaban @ Cumbayah.
Davide R.

7
@ DavideR. RFC menggunakan otentikasi dan otorisasi secara bergantian. Saya percaya itu lebih masuk akal ketika dibaca dengan makna otentikasi .
Zaid Masud

Jawaban ini dibalik. Tidak sah tidak sama dengan Tidak diautentikasi. @ DavidR benar. Otentikasi dan Otorisasi TIDAK dapat dipertukarkan
BozoJoe

2
2616 harus dibakar. Beberapa RFC baru jauh lebih jelas bahwa ada kebutuhan untuk membedakan antara "Saya tidak tahu Anda" dan "Saya tahu Anda tetapi Anda tidak dapat mengakses ini." Tidak ada alasan yang sah untuk mengakui keberadaan sumber daya yang tidak akan pernah terpenuhi (atau tidak dipenuhi melalui http), itulah yang disarankan oleh 403 orang yang benar.
Michael Blackburn

6

Inilah artinya:

401 : Pengguna tidak (dengan benar) diautentikasi, sumber / halaman ini memerlukan otentikasi

403 : Pengguna diautentikasi, tetapi peran atau izinnya tidak memungkinkan untuk mengakses sumber daya yang diminta, misalnya pengguna bukan administrator dan halaman yang diminta untuk administrator


Ini adalah jawaban TLDR yang bagus untuk pertanyaan ini.
Kousha

5

Ini lebih sederhana di kepala saya daripada di mana pun di sini, jadi:

401: Anda perlu autentikasi dasar HTTP untuk melihatnya.

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

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

Saya tidak merekomendasikan menggunakan 403 untuk menolak akses ke hal-hal seperti /includes, karena sejauh menyangkut web, sumber daya itu tidak ada sama sekali dan karenanya harus 404.

Ini meninggalkan 403 sebagai "Anda harus masuk".

Dengan kata lain, 403 berarti "sumber daya ini membutuhkan beberapa bentuk auth selain HTTP basic auth".

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


5

Saya pikir penting untuk mempertimbangkan bahwa, untuk browser, 401 memulai dialog otentikasi bagi pengguna untuk memasukkan kredensial baru, sedangkan 403 tidak. Peramban berpikir bahwa, jika 401 dikembalikan, maka pengguna harus mengautentikasi ulang. Jadi 401 adalah singkatan dari otentikasi tidak valid sementara 403 adalah singkatan dari kurangnya izin.

Berikut adalah beberapa kasus di bawah logika di mana kesalahan akan dikembalikan dari otentikasi atau otorisasi, dengan frasa penting yang dicetak tebal.

  • Sumber daya membutuhkan otentikasi tetapi tidak ada kredensial yang ditentukan .

401 : Klien harus menentukan kredensial.

  • Kredensial yang ditentukan dalam format yang tidak valid .

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

  • Kredensial yang ditentukan merujuk pengguna yang tidak ada .

401 : Klien harus menentukan kredensial yang valid.

  • Kredensial yang ditentukan tidak valid tetapi tentukan pengguna yang valid (atau jangan tentukan pengguna jika pengguna yang ditentukan tidak diperlukan).

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

  • Kredensial yang ditentukan telah kedaluwarsa .

401 : Ini secara praktis sama dengan memiliki kredensial tidak valid secara umum, sehingga klien harus menentukan kredensial yang valid.

  • Kredensial yang ditentukan benar-benar valid tetapi tidak mencukupi sumber daya tertentu , meskipun mungkin kredensial dengan lebih banyak izin bisa.

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 tertentu tidak dapat diakses terlepas dari kredensial.

403 : Ini terlepas dari kredensial, jadi menentukan kredensial yang valid tidak dapat membantu.

  • Kredensial yang ditetapkan benar-benar valid tetapi tertentu klien yang diblokir dari menggunakan mereka.

403 : Jika klien diblokir, menentukan kredensial baru tidak akan melakukan apa-apa.


4

Dalam Bahasa Inggris:

401

Anda berpotensi diizinkan mengakses tetapi karena suatu alasan permintaan ini Anda ditolak. Seperti kata sandi yang buruk? Coba lagi, dengan permintaan yang benar, Anda akan mendapatkan respons yang sukses.

403

Anda tidak pernah diizinkan. Nama Anda tidak ada dalam daftar, Anda tidak akan pernah masuk, pergi, jangan mengirim permintaan coba ulang, itu akan selalu ditolak. Pergi.


1

Mengingat RFC terbaru tentang masalah ini ( 7231 dan 7235 ) kasus penggunaan tampak cukup jelas (cetak miring ditambahkan):

  • 401 adalah untuk tidak diautentikasi ("tidak memiliki otentikasi yang valid"); yaitu 'Saya tidak tahu siapa Anda, atau saya tidak percaya Anda adalah siapa yang Anda katakan.'

401 Tidak Resmi

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan belum diterapkan karena tidak memiliki kredensial otentikasi yang valid untuk sumber daya target. Server yang menghasilkan respons 401 HARUS mengirim bidang header WWW-Otentikasi (Bagian 4.1) yang berisi setidaknya satu tantangan yang berlaku untuk sumber daya target.

Jika permintaan menyertakan kredensial autentikasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut. Agen pengguna DAPAT mengulangi permintaan dengan bidang tajuk Otorisasi baru atau yang diganti (Bagian 4.2). Jika respons 401 berisi tantangan yang sama dengan respons sebelumnya, dan agen pengguna telah mencoba otentikasi setidaknya satu kali, maka agen pengguna HARUS menyajikan representasi terlampir kepada pengguna, karena biasanya berisi informasi diagnostik yang relevan.

  • 403 adalah untuk yang tidak berwenang ("menolak untuk mengotorisasi"); yaitu 'Saya tahu siapa Anda, tetapi Anda tidak memiliki izin untuk mengakses sumber ini.'

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 dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada).

Jika kredensial otentikasi diberikan dalam permintaan, server menganggapnya tidak cukup untuk memberikan akses. Klien TIDAK HARUS mengulangi permintaan dengan kredensial yang sama. Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda. Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari sumber daya target terlarang MUNGKIN merespons dengan kode status 404 (Tidak Ditemukan).


2
-1; bagian-bagian ini telah dikutip dalam jawaban lain di sini, dan bagian Anda tidak menambahkan sesuatu yang baru. Saya berpendapat bahwa jelas tidak jelas apa perbedaannya; Anda merangkum kedua kode tersebut sebagai "tidak memiliki autentikasi yang valid" dan "menolak untuk mengotorisasi" tetapi saya tidak dapat memahami situasi apa pun di mana salah satu dari deskripsi singkat itu akan berlaku di mana yang lain tidak dapat diartikan berlaku juga.
Mark Amery

Ada banyak jawaban di sini yang mencakup banyak RFC dan diedit dan diperbarui memperkeruh perairan. Saya menyertakan tautan untuk menjelaskan apa authenticateditu dan apa authorizeddan meninggalkan semua RFC yang sudah ketinggalan zaman sehingga aplikasinya jelas.
cjbarth

Hasil edit Anda mengklarifikasi interpretasi Anda terhadap kedua kode tersebut, yang tampaknya cocok dengan interpretasi banyak orang lain. Namun, saya pribadi percaya bahwa penafsiran tidak masuk akal. Penggunaan frasa " Jika kredensial otentikasi disediakan" dalam deskripsi 403 menyiratkan bahwa 403 dapat sesuai bahkan jika tidak ada kredensial yang diberikan - yaitu kasus "tidak terauthentikasi". Sementara itu, bagi saya interpretasi yang paling alami dari frasa "untuk sumber daya target" yang dimasukkan dalam deskripsi 401 adalah bahwa 401 dapat digunakan untuk pengguna yang diautentikasi tetapi tidak diotorisasi.
Mark Amery

-6

Dalam kasus 401 vs 403, ini telah dijawab berkali-kali. Ini pada dasarnya adalah debat 'Lingkungan permintaan HTTP', bukan debat 'aplikasi'.

Tampaknya ada pertanyaan tentang masalah roll-your-own-login Anda (aplikasi).

Dalam hal ini, tidak login saja tidak cukup untuk mengirim 401 atau 403, kecuali jika Anda menggunakan HTTP Auth vs halaman login (tidak terikat dengan pengaturan HTTP Auth). Sepertinya Anda mungkin mencari "201 Created", dengan layar roll-your-own-login Anda (bukan sumber daya yang diminta) untuk akses tingkat aplikasi ke file. Ini mengatakan:

"Aku mendengarmu, ada di sini, tapi coba ini sebagai gantinya (kamu tidak diizinkan melihatnya)"


Apa sebenarnya yang sedang dibuat?
Grant Gryczan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.