Temu Duga Backend: Bagaimanakah Anda Mencegah BOLA/IDOR dalam API Multi-Penyewa?

Masalah dan Senario yang Berkenaan

Satu perkhidmatan dokumen B2B menggunakan database yang dikongsi. Seorang pengguna boleh menjadi ahli kepada beberapa penyewa dan mempunyai peranan viewer, editor, atau admin dalam setiap satu daripadanya. Dokumen juga boleh dikongsi secara terus dengan ahli daripada penyewa yang sama. Perkhidmatan ini mendedahkan API baca, kemas kini, dan padam dokumen tunggal, eksport pukal, serta penjanaan arkib secara tak segerak. Pengesahan tandatangan, tamat tempoh, dan audiens JWT sudah berfungsi, tetapi kod legasi memuatkan dokumen secara global menggunakan document_id yang dibekalkan oleh klien dan kemudiannya hanya menyemak sama ada permintaan tersebut telah disahkan ketulenannya.

Penyerang memperoleh UUID yang sah daripada entri audit, pautan perkongsian, atau API lain dan menggantikan ID dokumen mereka sendiri dengannya. UUID tersebut sukar untuk disenaraikan satu per satu, tetapi pelayan masih akan mendedahkan atau mengubah suai dokumen melainkan ia menyemak sama ada subjek semasa boleh melakukan tindakan ini ke atas sumber ini dalam penyewa yang aktif. OWASP menggelar perkara ini Broken Object Level Authorization (BOLA); bahan keselamatan web biasa juga menggunakan Insecure Direct Object Reference (IDOR). Pengenalpasti objek boleh muncul dalam laluan (path), parameter pertanyaan, pengepala (header), badan JSON, pemboleh ubah GraphQL, nama fail, atau senarai pukal.

Dua halaman persediaan temu duga API awam secara eksplisit meminta calon menerangkan atau menguji IDOR. Satu perbincangan awam pada Januari 2026 bertanya sama ada menyulitkan ID objek membetulkan IDOR, menunjukkan bahawa "sembunyikan ID" kekal sebagai tanggapan salah praktikal yang perlu dianalisis oleh calon. OWASP API Security Top 10 API1:2023 dan satu kajian empirikal awam 2026 menyediakan konteks risiko dan teknikal tambahan. Bukti ini menyokong keterwakilan; ia tidak menentukan soalan atau kekerapan temu duga bagi sesebuah syarikat tertentu.

Ini adalah soalan backend kerana tugas terasnya ialah membawa identiti yang disahkan ketulenannya, hubungan penyewa, atribut sumber, dan tindakan ke dalam satu sempadan kebenaran merentasi API, capaian data, transaksi, cache, dan worker. Artikel OAuth yang sedia ada merangkumi identiti dan aliran authorization-code, SQL injection merangkumi struktur pertanyaan, dan SSRF merangkumi kebenaran destinasi keluar. Tiada satu pun yang menjawab capaian peringkat objek.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah ketepatan terminologi. Pengesahan ketulenan (authentication) menjawab "siapakah yang memanggil?" Kebenaran (authorization) peringkat objek menjawab "bolehkah subjek ini melakukan tindakan ini ke atas objek ini sekarang?" Pengguna yang boleh memanggil PATCH /documents/{id} tetapi tidak boleh mengubah suai dokumen penyewa lain mendedahkan BOLA. Ahli biasa yang mencapai fungsi pemadaman pukal khusus untuk admin adalah lebih dekat kepada Broken Function Level Authorization. Membenarkan pengguna mengemas kini sifat owner_id yang dilindungi pada dokumen mereka sendiri ialah masalah kebenaran sifat objek.

Isyarat kedua ialah model kebenaran yang lengkap. Membandingkan document.owner_id == user.id sahaja terlepas peranan penyewa, perkongsian pasukan, hak baca sahaja, pembatalan (revocation), dan capaian sokongan sementara. Jawapan yang kukuh menjadikan satu keputusan eksplisit:

allow(subject, tenant, action, resource, context) -> decision + reason

Penyewa diperoleh daripada keahlian yang telah disahkan. Tindakan membezakan read, update, delete, share, dan export. Atribut sumber merangkumi penyewa, keadaan, pemilik, dan hubungan perkongsian. Konteks boleh mengandungi pemberian hak sokongan sementara dan versi dasar. Jika tiada peraturan izin (allow) yang sepadan, keputusannya adalah tolak (deny).

Isyarat ketiga ialah menguatkuasakan sempadan tempat data dipilih dan diubah. Memuatkan secara global dengan findById(id) dan bergantung pada satu pengawal (controller) untuk menambah semakan mewujudkan pintasan melalui titik akhir pukal, worker, cache, dan laluan baharu. Laluan yang disyorkan membuat pertanyaan daripada set data yang dibenarkan. Mutasi membawa syarat skop dan versi ke dalam pernyataan atau transaksi yang sama dan mengesahkan bilangan baris yang terjejas.

Isyarat keempat ialah memahami had pertahanan secara mendalam (defense-in-depth). UUID rawak, respons 404, pengehadan kadar (rate limits), dan PostgreSQL Row-Level Security (RLS) semuanya membantu, tetapi tiada satu pun yang menggantikan kebenaran perniagaan sepenuhnya. Dokumentasi PostgreSQL 18 juga menyatakan bahawa superuser, peranan BYPASSRLS, dan kebiasaannya pemilik jadual memintas RLS. Pengaktifan dasar, peranan sambungan, dan konteks penyewa bagi setiap permintaan mesti disahkan.

Isyarat terakhir ialah membuktikan bahawa setiap laluan menolak capaian rentas objek. GET yang berjaya untuk dokumen sendiri ialah ujian fungsian. Ujian keselamatan menggunakan berbilang akaun, penyewa, peranan, dan ID objek asing sah yang diketahui. Ujian ini merangkumi baca, tulis, padam, operasi pukal, eksport, muat turun, GraphQL, capaian cache, dan pelaksanaan worker, serta menegaskan (assert) bahawa tiada kesan sampingan database, storan objek, atau pemesejan yang berlaku.

Soalan untuk Diberi Penjelasan Sebelum Menjawab

• Bagaimanakah penyewa dipilih? Pengguna boleh menukar penyewa aktif, tetapi X-Tenant-ID klien hanya menyatakan

pilihan. Pelayan mesti mengesahkan semula keahlian bagi identiti yang disahkan ketulenannya dan bukannya mempercayai pengepala tersebut.

• Apakah yang menentukan kebenaran? Adakah ia hanya peranan penyewa, atau juga pemilikan, keahlian pasukan, perkongsian terus,

keadaan dokumen, dan pemberian sokongan sementara? Peraturan yang lebih dinamik memerlukan dasar berpusat dan sebab audit yang stabil.

• Tindakan manakah yang memerlukan kebenaran berasingan? Baca tidak merangkumi muat turun, eksport, kongsi,

atau padam secara automatik. Operasi pukal menggunakan keputusan peringkat tindakan yang sama pada setiap objek.

• Patutkah penolakan mengembalikan 403 atau 404? Jika ID objek luaran tidak sepatutnya mendedahkan kewujudan, tidak wujud dan tidak kelihatan

boleh berkongsi kontrak 404. Objek penyewa sama yang kelihatan dengan kebenaran tindakan yang tidak mencukupi boleh mengembalikan 403 di bawah kontrak produk. Kedua-dua respons tidak boleh mendedahkan perbezaan sensitif.

• Adakah tugas menggunakan kebenaran semasa atau snapshot masa penyerahan? Reka bentuk ini menyemak semasa masuk giliran (enqueue) dan sekali lagi semasa

pelaksanaan, jadi eksport yang beratur akan terhenti selepas pembatalan hak. Jika hak snapshot tidak boleh ubah (immutable) diperlukan, modelkan pemberian hak yang eksplisit, berskop, dan bertempoh tamat.

• Bolehkah kakitangan sokongan mengakses penyewa? Jika ya, gunakan laluan just-in-time berasingan yang memerlukan tiket, sebab,

kelulusan, masa tamat tempoh, dan audit penuh. Jangan berikan sambungan aplikasi umum suis global-admin yang kekal.

• Adakah PostgreSQL RLS akan digunakan? Jawapan ini menggunakan skop penyewa aplikasi sebagai kawalan utama dan RLS

terhadap peninggalan tidak sengaja (omissions). Gabungan lain adalah sah jika peranan database, konteks pool, migrasi, dan worker mengekalkan jaminan mereka.

Rangka Kerja Jawapan 30 Saat

"Saya akan menyatakan kebenaran sebagai subject + tenant + action + resource + context dan menolak secara lalai (deny by default). Middleware pengesahan ketulenan hanya menetapkan subjek. Penyewa aktif mesti datang daripada keahlian yang telah disahkan. Lapisan data tidak mendedahkan carian dokumen tanpa skop: operasi baca menggunakan tenant_id + document_id, diikuti oleh dasar tindakan ke atas peranan, pemilik, dan perkongsian. Kemas kini dan pemadaman membawa syarat tersebut ke dalam pernyataan atau transaksi yang sama; sifar baris terjejas dikendalikan sebagai tidak kelihatan. UUID mengurangkan enumerasi tetapi tidak pernah menggantikan kawalan capaian.

Laluan pukal, cache, muat turun, dan eksport menggunakan peraturan yang sama. Kunci cache menyertakan penyewa; pautan keupayaan (capability links) mengikat sumber, tindakan, dan masa tamat tempoh; dan tugas menyemak semasa masuk giliran dan pelaksanaan. PostgreSQL RLS boleh bertindak sebagai sandaran terhadap kesilapan, dengan syarat peranan aplikasi tidak boleh memintasnya dan penukaran penyewa pool diuji. Akhir sekali, saya akan menggantikan ID dalam laluan, badan, dan senarai pukal merentasi matriks dua penyewa dan pelbagai peranan serta menegaskan tiada respons, data, fail, atau mesej yang melintasi sempadan penyewa."

Penjelasan Terperinci Langkah demi Langkah

Langkah 1: Senaraikan tupel kebenaran dan titik masuk objek

Tulis peraturan perniagaan sebagai matriks sebelum menyebarkan nama peranan ke seluruh pengawal (controllers):

Jadual ini ialah andaian senario. Pemilik produk dan keselamatan mesti meluluskan matriks sebenar dan mewajarkan setiap peraturan izin. Tolak secara lalai bermaksud tindakan baharu, peranan tidak diketahui, konteks penyewa hilang, atau ralat dasar akan gagal secara tertutup (fail closed).

Kemudian senaraikan titik masuk objek: parameter laluan, penapis pertanyaan, badan, tatasusunan pukal, nod GraphQL, token perkongsian, kunci storan objek, kunci cache, mesej, dan tugas. Takrifan OWASP tidak memerlukan ID berurutan. UUID, nama fail, dan rentetan generik juga merupakan rujukan. Bagi setiap entri, rekodkan sumber subjek, sumber penyewa, tindakan, kaedah carian, dan kesan sampingan akhir. Proses itu mendedahkan laluan pintasan.

Langkah 2: Dapatkan penyewa yang dipercayai daripada identiti yang disahkan ketulenannya

JWT yang disahkan menyediakan user_id yang stabil; ia tidak menjadikan setiap tuntutan peranan jangka panjang terkini atau menjadikan ID penyewa yang dibekalkan secara berasingan dipercayai. Apabila pengguna memilih tenant_b, pelayan menyelesaikan keahlian semasa dan mencipta AuthContext berskop permintaan:

AuthContext {
  user_id,
  tenant_id,
  membership_id,
  roles,
  policy_version,
  support_grant_id?
}

Middleware memastikan konteks wujud; dasar domain tetap menentukan tindakan sumber. Pool sambungan, pengguna (consumers), dan permintaan serentak tidak boleh berkongsi penyewa global yang boleh berubah (mutable). Tetapkan konteks database di dalam setiap transaksi dan kosongkannya sebelum mengembalikan sambungan supaya satu permintaan tidak mewarisi penyewa sebelumnya.

Langkah 3: Masukkan skop penyewa ke dalam pertanyaan dan kekangan data

Pertanyaan yang tidak selamat memuatkan secara global:

SELECT * FROM documents WHERE id = :document_id;

Sempadan asas menyertakan penyewa yang dipercayai:

SELECT *
FROM documents
WHERE tenant_id = :auth_tenant_id
  AND id = :document_id;

Jika perkongsian terus menentukan keterlihatan, sertakan (join) hubungan perkongsian di dalam pertanyaan berskop atau muatkan hanya sumber penyewa yang sama dan hantarkannya ke enjin dasar berpusat. Jangan sekali-kali menyalin tenant_id daripada badan ke dalam predikat ini. Dari luar, sifar baris boleh secara konsisten menghasilkan 404 supaya "wujud dalam penyewa lain" dan "tidak wujud" tidak dapat dibezakan.

Reka bentuk skema menyukarkan berlakunya kesilapan. Jadual perkongsian, versi, lampiran, dan item eksport semuanya membawa tenant_id. Di mana sesuai, kunci unik dan asing menggunakan (tenant_id, resource_id) supaya anak dalam satu penyewa tidak boleh menunjuk kepada induk dalam penyewa lain. Kebenaran aplikasi kekal diperlukan; kekangan menolak hubungan rentas penyewa yang tidak disengajakan pada masa penulisan.

Langkah 4: Kekalkan kebenaran dan mutasi dalam satu sempadan ketepatan

"Muat, berikan kebenaran dalam kod aplikasi, kemas kini kemudian" mempunyai perlumbaan masa semak/masa guna (time-of-check/time-of-use). Kebenaran atau keadaan dokumen boleh berubah antara langkah-langkah tersebut. Dasar yang mudah boleh menggunakan kemas kini bersyarat:

UPDATE documents
SET title = :title, version = version + 1
WHERE tenant_id = :auth_tenant_id
  AND id = :document_id
  AND version = :expected_version
  AND (
    owner_id = :user_id
    OR :can_edit_tenant_documents
  );

Apabila sifar baris terjejas, jangan terbitkan mesej, tulis entri audit kejayaan, atau kemas kini cache. Perkongsian yang kompleks boleh mengunci keahlian dan versi sumber yang berkaitan dalam satu transaksi, atau menyusun dasar menjadi predikat database. Bukti kebenaran dan kesan sampingan mesti berkongsi sempadan transaksi/versi yang eksplisit; snapshot lama tidak boleh membenarkan penulisan kemudian yang tanpa syarat.

Operasi pukal memerlukan kontrak keatoman (atomicity). Senario ini menggunakan segalanya-atau-tiada (all-or-nothing): normalkan dan nyahduplikasi semua ID, buat pertanyaan bagi set yang dibenarkan di bawah satu penyewa dan tindakan yang dipercayai, dan tolak kumpulan tersebut jika bilangannya berbeza. Mengeksport subset yang kelihatan secara senyap-senyap boleh menjadi oracle kewujudan. Kontrak produk per-item juga boleh dilaksanakan, tetapi ia mesti membenarkan setiap objek dan menggunakan hasil yang tidak mendedahkan maklumat bagi item yang ditolak.

Langkah 5: Lindungi cache, muat turun, dan tugas tak segerak

Kunci cache mengandungi sekurang-kurangnya penyewa dan versi sumber, seperti document:{tenant_id}:{document_id}:{version}. Dapatan cache (cache hit) mengambil data; ia tidak melangkau kebenaran tindakan semasa. Jika keputusan dicache, kuncinya mesti merangkumi subjek, penyewa, tindakan, sumber, hubungan atau versi dasar, dan pembatalan hak. Sistem yang kompleks selalunya lebih selamat mencache data hubungan dan mengira semula keputusan yang kecil.

URL muat turun yang dipra-tandatangani (presigned) ialah keupayaan jangka pendek. Setelah dikeluarkan, pembawa boleh mencapai storan sepanjang hayatnya. Semak download sebelum mengeluarkannya dan ikat sumber, tindakan, tamat tempoh, dan disposisi kandungan. Dokumen sensitif menggunakan jangka hayat pendek, muat turun satu kali atau melalui proksi, dan pembatalan jika diperlukan. Tandatangan membuktikan pelayan telah mengeluarkan URL; ia tidak memberikan pemanggil tanpa kebenaran izin untuk mendapatkannya.

Eksport menyemak pada dua ketika. API mengesahkan export pada setiap dokumen sebelum memasukkannya ke dalam giliran. Semasa pelaksanaan, worker menggunakan rujukan subjek dan penyewa dalam tugas untuk memuatkan semula keahlian dan kebenaran sumber semasa. Keahlian yang dibatalkan, pertukaran penyewa, atau pemberian sokongan yang telah tamat tempoh menghentikan tugas sebelum artifak yang boleh dimuat turun wujud. Muatan (payload) tugas tidak boleh menerima bendera admin yang dibekalkan oleh pemanggil atau mengekalkan tatasusunan peranan selama-lamanya.

Langkah 6: Perlakukan PostgreSQL RLS sebagai pertahanan mendalam yang boleh diuji

Jadual yang dikongsi boleh mendayakan RLS supaya dasar menapis baris sedia ada mengikut penyewa transaksi yang dipercayai dan WITH CHECK mengekang baris yang disisipkan atau dikemas kini. Tolak secara lalai apabila tiada dasar dikenakan ialah mod kegagalan yang diingini. Sebelum pelepasan, sahkan semua perkara berikut:

• sambungan aplikasi bukan superuser, tiada BYPASSRLS, dan bukan pemilik jadual yang kebiasaannya

memintas dasar; gunakan FORCE ROW LEVEL SECURITY apabila sesuai;

• setiap transaksi menetapkan penyewa dan mengosongkannya sebelum kembali ke pool; konteks yang hilang menolak capaian dan bukannya memilih

penyewa lalai;

• USING meliputi baris lama yang kelihatan dan WITH CHECK meliputi baris baharu yang disisipkan atau dikemas kini;
• migrasi, sandaran (backups), worker, dan alat sokongan menggunakan peranan berasingan dan prosedur yang eksplisit;
• dasar permisif bergabung dengan OR secara lalai, jadi dasar yang ditambah tidak boleh meluaskan capaian secara tidak sengaja;

dasar subpertanyaan yang kompleks juga disemak untuk snapshot keserentakan dan kos.

RLS tidak boleh menyatakan setiap hubungan produk dan tidak boleh melindungi storan objek atau indeks carian yang memintas database. Dasar aplikasi memiliki semantik perniagaan penuh; RLS menghentikan kebocoran jika satu pertanyaan terlepas pandang skop penyewa. Uji kedua-dua lapisan terhadap matriks kebenaran yang sama untuk ketekalan.

Langkah 7: Reka bentuk ralat, audit, dan ujian yang boleh dibuktikan salah (falsifiable)

Bagi objek rentas penyewa atau tidak kelihatan, senario ini mengembalikan bentuk respons dan 404 yang seragam. Penolakan tidak mengembalikan tajuk, nama penyewa, pemilik, versi, saiz fail, atau petunjuk masa (timing hint) yang ketara. Pengehadan kadar mengurangkan enumerasi dan hingar audit, tetapi tuntutan keselamatan tidak pernah bergantung pada kegagalan penyerang untuk meneka UUID.

Audit pelaku, penyewa dipercayai, tindakan, perwakilan ID sumber yang terkawal, keputusan, kod sebab, versi dasar, pemberian hak sokongan, dan trace ID. Jangan log kandungan dokumen, keupayaan muat turun, atau JWT penuh. Isyarat yang berguna termasuk penolakan rentas penyewa, satu subjek yang memeriksa banyak objek yang hilang, ralat dasar, penolakan RLS, tugas yang dihentikan selepas pembatalan hak, dan penggunaan pemberian hak sokongan.

Matriks ujian merangkumi sekurang-kurangnya:

1. dua penyewa, setiap satu dengan pemilik, pelihat (viewer), editor, dan admin, ditambah pengguna yang dibatalkan haknya dan pengendali sokongan sementara;
2. sumber milik sendiri, penyewa sama tidak dikongsi, dikongsi secara terus, UUID sah penyewa lain, dan UUID yang tidak wujud;
3. senarai, GET, PATCH, DELETE, kongsi, eksport pukal, GraphQL, muat turun, capaian cache, dan pelaksanaan worker;
4. penggantian dalam laluan, pertanyaan, JSON, tatasusunan, pemboleh ubah GraphQL bersarang, kunci storan, dan muatan tugas;
5. tiada kebocoran respons pada bacaan dan tiada perubahan versi, perkongsian, fail, mesej, indeks carian, atau audit kejayaan pada penolakan;
6. pembatalan hak dan kemas kini serentak, penggunaan penyewa berturut-turut bagi satu sambungan pool, konteks RLS yang hilang,

peranan aplikasi yang salah dikonfigurasi, dan cache kebenaran yang basi (stale).

Jana kes CI positif dan negatif daripada matriks kebenaran, dan wajibkan setiap titik akhir baharu mendaftarkan sumber dan tindakannya. Pengimbas menemui beberapa laluan yang boleh dienumerasi, tetapi mereka tidak mengetahui pemilikan perniagaan. Berbilang akaun, objek asing sah yang diketahui, dan penegasan kesan sampingan adalah bukti penentu di sini.

Contoh Jawapan Berkualiti Tinggi

"Saya akan mengklasifikasikan kecacatan ini sebagai BOLA. JWT membuktikan identiti pemanggil, manakala API kekurangan kebenaran peringkat tindakan bagi dokumen sasaran. UUID mengurangkan kebarangkalian enumerasi tetapi tidak mengubah keputusan kebenaran. Saya mula-mula akan mentakrifkan matriks subject, tenant, action, resource, context dan menolak secara lalai. Pengguna boleh memilih penyewa aktif, tetapi pelayan memperoleh konteks penyewa daripada keahlian semasa yang disahkan.

Lapisan data tidak lagi mendedahkan findById global kepada laluan perniagaan. Operasi baca mula-mula menskopkan mengikut tenant_id + document_id yang dipercayai, kemudian menggunakan peraturan peranan, pemilikan, dan perkongsian untuk read, update, delete, share, atau export. Kemas kini mudah membawa syarat penyewa, objek, tindakan, dan versi sumber dalam satu pernyataan bersyarat. Sifar baris terjejas menghentikan setiap kesan sampingan. Dasar kompleks memegang versi yang berkaitan dalam satu transaksi. Kunci asing penyewa komposit menghalang hubungan anak rentas penyewa.

Saya akan menyertakan setiap pintasan dalam model tersebut. Eksport pukal membenarkan setiap ID dan bersifat segalanya-atau-tiada di sini. Kunci cache menyertakan penyewa dan dapatan cache tetap memberi kebenaran semula. Pautan muat turun memerlukan kebenaran download semasa pengeluaran dan mengikat objek pada masa tamat tempoh yang singkat. Tugas menyemak semasa masuk giliran dan pelaksanaan supaya pembatalan hak berkuat kuasa sebelum eksport. RLS ialah sandaran, tetapi peranan aplikasi mesti tiada BYPASSRLS dan pemilikan jadual, dan konteks transaksi pool mesti diuji untuk kebocoran penyewa.

Akhir sekali, saya akan menggunakan akaun pelbagai peranan merentasi dua penyewa dan meletakkan satu UUID asing sah yang diketahui ke dalam laluan, JSON, senarai pukal, dan GraphQL. Ujian meliputi laluan baca, tulis, padam, eksport, muat turun, cache, dan worker. Setiap penolakan menegaskan respons yang tidak mendedahkan maklumat dan tiada perubahan versi database, fail, mesej, atau indeks carian. Ini membuktikan kebenaran peringkat objek laluan demi laluan sambil merangkumi log masuk, respons ralat, dan kesan sampingan."

Kesilapan Biasa

• Menganggap UUID, Base64, atau ID yang disulitkan sebagai penyelesaian → ID bocor melalui log, perkongsian, atau API lain, dan rujukan

yang sah masih melintasi sempadan → **Beri kebenaran kepada subjek, penyewa, objek, dan tindakan pada setiap permintaan; gunakan ID rawak hanya sebagai pertahanan mendalam.**

• Membenarkan sebarang ID selepas pengesahan ketulenan JWT → Pengesahan ketulenan mengenal pasti subjek tetapi tidak memberikan hak sumber →

Bina konteks penyewa daripada keahlian yang disahkan dan kemudian buat keputusan objek.

• Memuatkan secara global dalam pengawal dan menulis sendiri semakan pemilik secara manual → Laluan baharu, pukal, cache, dan worker mengabaikannya,

manakala perkongsian pasukan dinafikan secara salah → Dedahkan capaian data berskop penyewa dan dasar berpusat dengan penolakan secara lalai.

• Hanya menguji GET → PATCH, DELETE, eksport, GraphQL, dan muat turun mungkin masih bocor atau bermutasi → **Jana

matriks negatif berbilang akaun merentasi titik masuk dan tindakan.**

• Menapis ID yang ditolak keluar daripada kelompok yang berjaya → Bilangan dan kandungan menjadi oracle kewujudan, dan kejayaan separa

menjadi samar-samar → Pratakrifkan semantik segalanya-atau-tiada atau per-item dan berikan kebenaran bagi setiap objek.

• Menganggap RLS ialah keselamatan automatik → Pemilik jadual, superuser, BYPASSRLS, konteks hilang, dan gubahan dasar permisif

boleh memecahkan pengasingan → Sahkan peranan, konteks transaksi, USING/WITH CHECK, dan mod kegagalan.

• Hanya menegaskan 403 atau 404 → Sistem mungkin telah menulis data, menghantar mesej, atau menjana fail sebelum penolakan →

Tegaskan setiap kesan sampingan yang berterusan dan luaran kekal tidak berubah.

• Mencatat log objek dan token penuh untuk siasatan → Telemetri keselamatan menjadi satu lagi kebocoran data → **Rekodkan

identiti minimum, tindakan, sebab, dan pengenalpasti sumber yang terkawal.**

Soalan Susulan dan Maklum Balas

Susulan 1: Jika UUIDv4 secara praktikalnya mustahil diteka, adakah kebenaran objek masih diperlukan?

Ya. Rujukan bocor melalui pautan perkongsian, sejarah penyemak imbas, log, pemberitahuan, analitik, API lain, atau mesej yang salah dihantar. UUID mengurangkan enumerasi buta; ia tidak menyatakan pemilik, penyewa, tindakan, atau masa tamat tempoh. Berikan akaun penyerang satu UUID asing sah yang diketahui dalam ujian. Capaian yang berjaya membuktikan ketiadaan kebenaran dengan serta-merta.

Susulan 2: Adakah mengembalikan 404 bagi setiap objek rentas penyewa menjadikan penyahpepijatan terlalu sukar?

Respons luaran boleh dibuat seragam manakala audit dalaman mengekalkan sebab yang stabil seperti RESOURCE_NOT_VISIBLE, ACTION_DENIED, atau TENANT_CONTEXT_INVALID. Pengendali menyiasat melalui log terkawal dan trace ID; pemanggil tidak mengetahui sama ada sesuatu objek wujud. Jika kolaborasi penyewa sama memerlukan "tiada kebenaran mengedit," kembalikan 403 hanya selepas menetapkan bahawa objek tersebut kelihatan, di bawah kontrak API yang konsisten.

Susulan 3: Apakah yang berlaku kepada eksport yang berada dalam giliran apabila pengguna dikeluarkan daripada penyewa?

Penyerahan yang berjaya tidak mencipta autoriti membaca yang kekal. Sebelum pelaksanaan, muat semula keahlian dan kebenaran export bagi setiap sumber. Selepas pembatalan hak, tolak tugas tersebut, padam fail sementara, dan jangan keluarkan URL muat turun. Jika pematuhan memerlukan hak dibekukan semasa penyerahan, cipta snapshot kebenaran jangka pendek yang eksplisit dengan skop, pelulus, dan masa tamat tempoh dan bukannya mengekalkan peranan JWT lapuk secara senyap-senyap.

Susulan 4: Jika setiap pertanyaan aplikasi sudah menyertakan tenant_id, apakah yang ditambah oleh RLS?

Ia boleh menghentikan pertanyaan baharu yang tertinggal predikat dan beberapa laluan database terus, mengurangkan radius kesan bagi satu ketinggalan. Ia juga menambah kos konteks pool, peranan, migrasi, dan penyelenggaraan dasar serta tidak dapat melindungi carian, cache, atau storan objek. Jadual berkongsi dengan tahap sensitiviti tinggi ialah calon yang baik untuk kedua-dua lapisan. Mula-mula buktikan bahawa peranan aplikasi tidak boleh memintas RLS, konteks penyewa yang hilang menolak capaian, konteks pool tidak bocor, dan kedua-dua lapisan sepadan dengan matriks yang sama.

Susulan 5: Jurutera sokongan memerlukan capaian dokumen pelanggan sementara. Bagaimanakah anda mengelakkan pintu belakang kekal?

Cipta kebenaran sokongan just-in-time berasingan yang terikat pada tiket, penyewa sasaran, tindakan yang dibenarkan, pelulus, tamat tempoh singkat, dan sebab. Tindakan sensitif boleh memerlukan kelulusan dua orang. Asingkan titik akhir sokongan dan biasa, tunjukkan keadaan sesi yang jelas, larang muat turun pukal, dan audit setiap capaian objek. Penamatan tempoh membatalkan capaian serta-merta, dan penggunaannya disemak secara berkala. Peranan aplikasi umum dan token perkhidmatan tidak menerima sebarang kebenaran rentas penyewa.