← News & Analysis
Cloud Access & Developer SecurityCLOUDFLAREBARU

Protected Quick Tunnels: preview localhost kini bisa dibatasi lewat email

Preview aplikasi lokal terasa aman karena berjalan di laptop sendiri. Begitu diterbitkan melalui tunnel, siapa yang bisa membuka URL menjadi keputusan keamanan yang nyata. Pada 2 Oktober 2026, Cloudflare mengumumkan Protected Quick Tunnels: pembatasan akses berdasarkan email tanpa mewajibkan akun Cloudflare pada pembuat atau pengunjung. Buat engineer yang membagikan demo, termasuk preview dari coding agent, perubahan ini menarik karena kontrol akses bisa dimasukkan ke langkah publikasi yang singkat. Tetap ada batas penggunaan yang perlu dipahami sebelum menyamakan preview dengan layanan production.

HTTP service lokal
Quick Tunnel dengan allowed-mail
Verifikasi email
Pemeriksaan allowlist lokal
Preview untuk tamu yang diizinkan

Apa yang berubah?

Pengumuman Cloudflare menyebut dukungan mulai cloudflared 2026.9.3. Flag --allowed-mail menambahkan autentikasi dengan PIN email; Cloudflare Access memverifikasi penguasaan mailbox dan cloudflared mencocokkan email dengan aturan lokal. Jika flag tidak digunakan, Quick Tunnel tetap publik. Menurut desain yang diumumkan, mode terlindungi tidak turun otomatis menjadi publik ketika pemeriksaan gagal. Jadi keberadaan URL acak saja tetap bukan kontrol akses.

Contoh penggunaan yang harus disesuaikan

Dokumentasi mengizinkan email tertentu, pengulangan flag, atau wildcard domain. Contoh berikut hanya ilustrasi untuk service lab milik sendiri dan belum dijalankan sebagai pengujian Cloud Network Lab. Ganti alamat dokumentasi dengan tamu yang benar-benar diizinkan. Sebelum membagikan URL, periksa versi connector dan pastikan output menunjukkan autentikasi email aktif.

cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]

Analisis: masalahnya bukan hanya siapa mengetahui link

URL preview dapat terbawa ke chat, tiket, rekaman rapat, atau keluaran agent. Tim sebaiknya menganggap pembatasan akses sebagai bagian dari pembuatan preview, bukan pekerjaan tambahan setelah link dibagikan. Dengan pendekatan ini, perubahan desain yang belum siap, endpoint debug, dan data contoh punya batas akses yang eksplisit. Namun pembatasan tamu tidak memperbaiki kerentanan aplikasi dan tidak membuat data sensitif layak dipakai untuk demo.

Allowlist satu alamat dan satu domain punya dampak berbeda

Wildcard domain berarti setiap mailbox yang cocok berpotensi mendapat akses. Untuk review kecil, alamat spesifik lebih mudah dipertanggungjawabkan. Untuk tim besar, tentukan siapa yang mengelola mailbox dan apakah domain tersebut dipakai pihak di luar kelompok reviewer. Kepemilikan email bukan bukti jabatan atau izin melihat semua data dalam aplikasi. Tetap pisahkan data demo dan hak akses aplikasi jika fitur yang dipreview punya beberapa tingkat privilege.

Browser interaktif membatasi jenis integrasi

Quick Tunnels docs menyebut autentikasi email memerlukan sesi browser interaktif dan tidak mendukung client noninteraktif. Dokumentasi juga menetapkan tidak ada jaminan uptime, hostname berubah saat tunnel baru dibuat, batas 200 request in-flight dengan respons 429 untuk kelebihan, serta tidak mendukung SSE. Artinya, preview untuk manusia dan endpoint untuk webhook atau MCP server otomatis memiliki kebutuhan berbeda. Evaluasi mekanisme autentikasi yang sesuai sebelum mengandalkan alur email untuk integrasi mesin.

Validasi akses positif dan negatif

Rekomendasi editorial kami: buka link dari sesi browser bersih sebagai tamu yang diizinkan, lalu uji alamat lab yang tidak diizinkan. Cocokkan hasil dengan log aplikasi lokal untuk memastikan penolakan tidak mencapai handler. Jangan hanya melihat halaman login lalu menyatakan proteksi berhasil. Uji juga URL fitur yang relevan pada preview, sebab halaman depan yang benar belum membuktikan alur aplikasi lain berfungsi. Gunakan akun uji dan hindari memasukkan data pelanggan.

Coding agent tetap membutuhkan batas publikasi yang jelas

Agent yang menghasilkan aplikasi bisa memilih command publikasi berdasarkan konteks yang tidak lengkap. Karena itu, tetapkan alamat reviewer, port yang boleh diekspos, dan data yang boleh muncul sebelum membuka tunnel. Review command yang benar-benar dijalankan, bukan hanya deskripsi agent. Jika ada beberapa server lokal, pastikan service yang dituju sesuai. Kontrol singkat berguna karena mudah diterapkan konsisten; efektivitasnya tetap bergantung pada pemilihan target dan izin yang benar.

Akhiri akses ketika review selesai

Dokumentasi meminta penghentian proses dan pembuatan tunnel baru untuk mengubah daftar tamu; akses berakhir ketika proses berhenti. Rekomendasi kami: jadikan penutupan preview bagian dari checklist review, catat siapa pemilik proses, dan verifikasi link lama tidak lagi membuka aplikasi. Jangan menganggap menutup tab browser menghentikan connector. Untuk demo yang perlu kembali esok hari, buat ulang dengan daftar akses yang ditinjau kembali.

Kapan harus memakai desain production?

Cloudflare menempatkan Quick Tunnels untuk testing dan development. Hostname tetap, integrasi identitas organisasi, layanan otomatis, dan kebutuhan availability memerlukan desain yang lebih matang. Secara engineering, tentukan monitoring, lifecycle credential, owner, logging, dan recovery sesuai layanan tersebut. Takeaway-nya: update ini mengurangi friksi membatasi tamu pada preview sementara. Ia bukan alasan untuk menjalankan aplikasi internal permanen lewat link sementara atau menghilangkan autentikasi aplikasi.

Sumber utama

Cloudflare Blog — Protected Quick Tunnels (2 Oktober 2026) ↗Cloudflare Docs — Quick Tunnels, access rules and limitations ↗
Lihat semua News & Analysis →