HTTP

Keamanan Siber / 24 Sep 2026 / 5 min read

security.txt Menerbitkan Jalur Pelaporan Kerentanan dengan Batas yang Jelas

Sebuah celah keamanan dapat sulit dilaporkan meski layanan yang terdampak mudah diidentifikasi. Formulir dukungan umum dapat mengirim pesan ke antrean yang salah, mailbox keamanan lama mungkin tidak lagi dipantau, dan peneliti tidak dapat menganggap sebuah kebijakan disclosure berlaku hanya dari nama perusahaan. RFC 9116 menangani masalah routing tersebut melalui security.txt, file kecil yang dapat diproses mesin dan diterbitkan operator layanan. File ini tidak menyatakan bahwa sebuah layanan aman, tidak memberi izin untuk melakukan pengujian, dan tidak mendefinisikan seluruh program vulnerability disclosure. Tugasnya lebih sempit: menerbitkan jalur pelaporan yang masih berlaku beserta metadata terkait pada lokasi yang dapat diprediksi.

Cybersecurity Vulnerability Disclosure

Keamanan Siber / 24 Sep 2026 / 5 min read

HTTP Message Signatures Mengikat Komponen HTTP yang Dipilih

TLS melindungi pertukaran HTTP selama trafik bergerak melalui koneksi TLS, tetapi beberapa desain aplikasi memerlukan pernyataan kriptografis yang melekat pada pesan HTTP itu sendiri. Gateway dapat menghentikan TLS sebelum meneruskan request, layanan dapat perlu mengautentikasi metadata request tertentu, atau pesan dapat melewati beberapa hop HTTP ketika perlindungan transport dan kepercayaan aplikasi berada pada batas yang berbeda. HTTP Message Signatures, yang ditetapkan dalam RFC 9421, menangani batas tersebut. Signer memilih komponen pesan HTTP, membentuk signature base sesuai aturan, menandatanganinya, lalu mengirim metadata yang memberi tahu verifier komponen dan parameter yang tercakup. Mekanisme ini sengaja bersifat selektif: sebuah tanda tangan tidak otomatis mencakup setiap field atau setiap properti pesan.

Cybersecurity HTTP

Keamanan Siber / 24 Sep 2026 / 4 min read

HSTS Menutup Jalur Downgrade HTTPS pada Koneksi Berikutnya

TLS melindungi koneksi HTTPS setelah klien memilih HTTPS dan menyelesaikan TLS handshake. Masih ada persoalan terpisah pada batas skema. Pengguna dapat mengetik hostname tanpa skema, membuka tautan lama http://, atau mencapai redirect yang dimulai melalui cleartext. Penyerang yang mampu mengganggu pertukaran HTTP pertama dapat mencoba mempertahankan browser agar tidak beralih ke HTTPS. HTTP Strict Transport Security (HSTS), yang didefinisikan dalam RFC 6797, memindahkan keputusan tersebut ke user agent. Setelah sebuah host mengirim header Strict-Transport-Security yang valid melalui koneksi aman, user agent yang sesuai menyimpan kebijakan itu. Selama masa berlakunya, percobaan berikutnya untuk menghubungi host tersebut melalui HTTP diubah menjadi HTTPS sebelum request HTTP dikirim.

Cybersecurity HTTPS

Keamanan Siber / 23 Sep 2026 / 6 min read

HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya

HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya TLS melindungi koneksi HTTP setelah klien memakai HTTPS. Pengguna yang mengetik hostname tanpa skema, mengikuti tautan lama http://, atau membuka endpoint HTTP yang melakukan redirect masih dapat memulai sesi dengan request tanpa enkripsi. HTTP Strict Transport Security (HSTS) memberi browser yang mendukungnya aturan persisten untuk host tersebut. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, browser menyimpan kebijakan itu dan mengubah navigasi HTTP berikutnya menjadi HTTPS selama kebijakan masih aktif.

Cybersecurity HTTPS

Rekayasa Perangkat Lunak / 22 Sep 2026 / 7 min read

Optimistic Concurrency Menolak Write Stale Sebelum Mengganti State yang Lebih Baru

Optimistic Concurrency Menolak Write Stale Sebelum Mengganti State yang Lebih Baru Alur read-modify-write terlihat sederhana ketika hanya satu actor menyentuh sebuah record. Client membaca state, mengubah sebagian isinya, lalu menulis hasilnya kembali. Saat beberapa actor bekerja bersamaan, jeda antara read dan write menjadi race. Writer lain dapat melakukan commit terhadap nilai yang lebih baru pada jeda tersebut, lalu update tanpa kondisi dapat menghapusnya. Optimistic concurrency control menambahkan kondisi pada write terakhir. Client membawa version yang berasal dari state yang dibacanya, dan storage layer menerima mutation hanya jika version itu masih current. Ketidakcocokan menjadi conflict, bukan overwrite yang tidak terlihat.

Rekayasa Perangkat Lunak Concurrency

Keamanan Siber / 21 Sep 2026 / 5 min read

Prefix Cookie __Host- Mempersempit Scope Cookie Sesi

Prefix Cookie __Host- Mempersempit Scope Cookie Sesi Cookie sesi dapat membawa identifier acak yang kuat tetapi tetap memiliki scope yang terlalu luas. Atribut Domain dapat membuat cookie tersedia di berbagai subdomain, sedangkan cookie dengan path tertentu dapat berdampingan dengan cookie bernama sama. Detail tersebut penting ketika beberapa aplikasi berbagi registrable domain tetapi tidak berbagi security boundary yang sama. Prefix nama cookie __Host- memberi user agent yang mendukungnya sekumpulan aturan ringkas untuk cookie yang lebih ketat. Cookie dengan nama yang diawali __Host- harus ditetapkan dari secure origin dengan Secure, harus memakai Path=/, dan tidak boleh memiliki Domain. User agent yang menerapkan prefix ini menolak cookie berprefix tersebut jika constraint itu dilanggar.

Keamanan Siber HTTP

Keamanan Siber / 21 Sep 2026 / 4 min read

Permissions Policy Membatasi Fitur Browser Berkemampuan Tinggi

Permissions Policy Membatasi Fitur Browser Berkemampuan Tinggi Sebuah halaman web dapat memuat kode dari beberapa domain kepercayaan sambil tetap berbagi akses ke kapabilitas browser. Script pihak pertama, widget pihak ketiga, dan nested frame dapat berjalan dalam satu permukaan aplikasi. Prompt izin browser tetap penting, tetapi aplikasi dapat mempersempit dokumen yang berhak meminta atau memakai fitur tertentu sebelum prompt menjadi relevan. Permissions Policy menyediakan batas tersebut. Header response menyatakan origin mana yang boleh memakai fitur terkontrol di dalam dokumen dan frame tree-nya. Policy ini tidak memberikan izin pengguna. Fungsinya membatasi ketersediaan fitur di browser.

Keamanan Siber Keamanan Web

Keamanan Siber / 21 Sep 2026 / 5 min read

Header Fetch Metadata Menyaring Request Cross-Site

Header Fetch Metadata Menyaring Request Cross-Site Server web sering menerima request yang tampak valid pada lapisan HTTP meski berasal dari situs yang tidak berkaitan. Cookie dapat ikut terkirim, dan endpoint yang mengubah state dapat terekspos jika pertahanannya memperlakukan setiap request browser dengan tingkat kepercayaan yang sama. Fetch Metadata memberi server konteks tambahan. Browser yang mendukung mekanisme ini memasang header request Sec-Fetch-* yang menjelaskan hubungan antara initiator dan target, mode request, destination, serta apakah navigasi berasal dari aktivasi langsung pengguna. Server dapat memakai konteks tersebut sebagai gerbang awal untuk isolasi resource.

Cybersecurity Keamanan Web

Keamanan Siber / 21 Sep 2026 / 5 min read

Cookie SameSite Membatasi Pengiriman Sesi Lintas Situs

Cookie SameSite Membatasi Pengiriman Sesi Lintas Situs Cookie sesi merupakan kredensial ambient: setelah tersimpan, browser dapat menyertakannya pada request HTTP yang cocok tanpa kode aplikasi menyalin nilainya ke setiap request. Kemudahan itu sekaligus membentuk batas keamanan. Request yang dimulai dari situs lain dapat mencapai aplikasi sambil membawa sesi terautentikasi milik pengguna jika policy cookie tidak mencegahnya. Atribut SameSite memberi browser aturan untuk menentukan apakah cookie boleh menyertai request dalam konteks lintas situs. Atribut ini tidak mengubah nilai cookie dan tidak mengautentikasi request dengan sendirinya. Yang diatur adalah kapan browser menyertakan cookie tersebut.

Cybersecurity HTTP

Keamanan Siber / 20 Sep 2026 / 7 min read

Percayai Header Forwarding Hanya dari Proxy yang Dikenal

Percayai Header Forwarding Hanya dari Proxy yang Dikenal Reverse proxy sering mengetahui fakta yang tidak dapat diamati langsung oleh application server. Proxy dapat menghentikan TLS, menerima hostname publik, dan menerima koneksi client sebelum membuka koneksi terpisah ke backend. Field forwarding membawa fakta tersebut melewati hop kedua. Susunan ini aman hanya jika backend dapat membedakan metadata dari proxy dengan field HTTP yang dikirim client. Nama header tidak menciptakan kepercayaan. Kepercayaan berasal dari jalur jaringan, konfigurasi proxy, dan aturan yang menentukan hop mana yang boleh menetapkan atau mengganti setiap field.

Cybersecurity Reverse Proxy

Keamanan Siber / 20 Sep 2026 / 7 min read

Early Data TLS Memerlukan Semantik Aplikasi yang Aman terhadap Replay

Early Data TLS Memerlukan Semantik Aplikasi yang Aman terhadap Replay TLS 1.3 dapat membawa application data pada flight pertama client ketika client dan server berbagi pre-shared key (PSK) yang sesuai, umumnya dari koneksi sebelumnya. Mode ini disebut early data atau 0-RTT. Mekanisme tersebut menghilangkan waktu tunggu handshake dari critical path untuk traffic aplikasi yang memenuhi syarat, tetapi pengurangan latensi itu datang dengan kontrak keamanan yang lebih sempit. Batas utamanya adalah replay. TLS tidak memberikan jaminan non-replay untuk data 0-RTT di antara koneksi. Server dapat menerapkan mekanisme anti-replay, tetapi aplikasi tetap harus memperlakukan early data sebagai data yang berpotensi diputar ulang. Perbedaan ini penting ketika satu request yang diterima dapat mengubah state persisten, memakai capability sekali pakai, memicu tindakan eksternal, atau menghasilkan efek lain yang seharusnya hanya terjadi satu kali.

Cybersecurity TLS 1.3

Rekayasa Perangkat Lunak / 19 Sep 2026 / 5 min read

Precondition ETag Mencegah Lost Write pada API Update HTTP

Dua client dapat membaca resource yang sama, mengedit field berbeda, lalu mengirim update dengan selang beberapa detik. Jika server menerima kedua write tanpa memeriksa representasi yang menjadi dasar edit masing-masing client, request yang datang belakangan dapat diam-diam menggantikan state dari write sebelumnya. Transport berhasil, tetapi aplikasi kehilangan perubahan konkuren. HTTP menyediakan mekanisme conditional request untuk batas ini. Server dapat menyertakan entity tag pada representasi, lalu client mengirim kembali tag tersebut melalui If-Match saat mengajukan request yang mengubah state. Update hanya berjalan selama representasi yang dipilih masih memenuhi precondition yang diberikan.

Rekayasa Perangkat Lunak HTTP

Keamanan Siber / 19 Sep 2026 / 6 min read

Perbedaan Framing HTTP/1.1 Membentuk Batas Request Smuggling

Perbedaan Framing HTTP/1.1 Membentuk Batas Request Smuggling Satu koneksi HTTP/1.1 dapat membawa beberapa request secara berurutan. Setiap recipient karena itu harus menentukan secara tepat posisi akhir satu request sebelum mem-parsing request berikutnya. Pada koneksi langsung dari client ke origin, satu parser mengambil keputusan tersebut. Dalam deployment dengan reverse proxy, gateway, load balancer, cache, atau intermediary lain, byte stream yang sama dapat melewati beberapa parser sebelum mencapai kode aplikasi. Request smuggling dapat terjadi ketika recipient yang berdekatan menetapkan batas berbeda terhadap byte yang sama. Masalahnya bukan sekadar header malformed yang mencapai aplikasi. Masalah tersebut merupakan perbedaan antara state machine protokol: satu recipient menganggap request telah selesai sementara recipient lain masih memperlakukan sebagian byte sebagai body, atau sebaliknya. Byte yang tersisa pada persistent connection kemudian dapat ditafsirkan dalam konteks request yang berbeda.

Keamanan Siber HTTP

Rekayasa Perangkat Lunak / 19 Sep 2026 / 7 min read

Idempotency Key Mengikat Retry ke Satu Mutasi Logis

Client dapat kehilangan HTTP response setelah server melakukan commit terhadap mutasi yang diminta. Dari sisi client, status operasi belum pasti: koneksi gagal, tetapi kegagalan itu tidak menunjukkan apakah durable state sudah berubah. Retry terhadap POST yang sama kemudian dapat membuat order, percobaan pembayaran, reservasi, atau mutasi lain untuk kedua kalinya. Idempotency key memberi retry sebuah identitas stabil yang terpisah dari satu percobaan transport tertentu. Server dapat mengaitkan request berulang yang membawa identitas tersebut dengan satu operasi logis. Mekanisme ini mempersempit ambiguitas pada batas API, tetapi key saja bukan jaminan. Scope, persistensi, perbandingan request, kontrol konkurensi, dan kebijakan replay menentukan arti sebenarnya dari pengiriman berulang.

Software Engineering HTTP

Keamanan Siber / 19 Sep 2026 / 6 min read

Header Fetch Metadata Membentuk Batas Request Lintas Situs di Sisi Server

Browser dapat mengirim request terautentikasi ke sebuah situs dari dokumen yang di-host di tempat lain. Cookie dapat menyertai request tersebut sesuai atribut cookie, sementara same-origin policy tetap dapat mencegah halaman pemicu membaca respons. Bagi server, perbedaan ini penting: pemblokiran akses terhadap respons tidak selalu menghentikan request lintas situs agar tidak mencapai endpoint. Fetch Metadata menambahkan konteks request ke batas ini. User agent yang mendukung mekanisme tersebut memasang header request Sec-Fetch-* yang menjelaskan relasi serta properti request agar dapat dievaluasi server sebelum logika aplikasi menjalankan tindakan sensitif. Kebijakan dapat menolak request karena bersifat lintas situs, sekaligus mempertahankan alur navigasi atau resource publik tertentu.

Keamanan Siber Keamanan Web

JavaScript / 19 Sep 2026 / 4 min read

Axios GET Menggunakan Satu Config Object untuk Params dan Headers

axios.get() menerima URL request dan satu configuration object opsional. Query parameter dan HTTP header bukan argumen posisi yang terpisah; keduanya merupakan properti dari configuration object tersebut. Batas ini penting karena kode yang memperlakukan params dan headers sebagai dua config argument terpisah dapat menjadi JavaScript yang tidak valid atau menaruh konfigurasi di posisi yang tidak dibaca Axios. Method GET memiliki satu batas config Bentuk pemanggilannya adalah: axios.get(url, config) Request configuration dapat memuat beberapa kebutuhan sekaligus:

JavaScript Axios

Keamanan Siber / 17 Sep 2026 / 6 min read

HTTP Request Smuggling Berawal dari Perbedaan Framing Pesan

HTTP Request Smuggling Berawal dari Perbedaan Framing Pesan Reverse proxy dapat memvalidasi request HTTP, meneruskannya ke aplikasi yang diizinkan, tetapi tetap mengirim urutan request yang berbeda dari yang dianggapnya telah diterima. Kegagalan ini tidak mengharuskan proxy mengabaikan autentikasi atau origin menjalankan sintaks yang rusak. Masalah dapat muncul ketika dua pemroses HTTP berbeda pendapat tentang byte yang menandai akhir satu request dan awal request berikutnya. Perbedaan itulah batas keamanan utama pada HTTP request smuggling. Front end membaca stream dengan satu interpretasi framing, sedangkan penerima downstream membaca stream yang diteruskan dengan interpretasi lain. Byte yang dianggap body oleh satu komponen dapat dianggap awal request baru oleh komponen lain. Pada koneksi persisten, interpretasi kedua dapat memengaruhi trafik yang datang kemudian pada channel downstream yang sama.

Cybersecurity HTTP

Keamanan Siber / 17 Sep 2026 / 8 min read

Fetch Metadata Mengekspos Konteks Request Browser di Batas Server

Fetch Metadata Mengekspos Konteks Request Browser di Batas Server Endpoint yang mengubah state dapat menerima dua HTTP request dengan method, path, cookie, dan body yang sama walaupun browser mencapainya melalui konteks yang sangat berbeda. Satu request mungkin berasal dari document milik aplikasi sendiri. Request lain mungkin dipicu foreign site melalui form, image load, navigation, atau mekanisme browser lain yang mengizinkan request tanpa memberi initiating page akses ke response. Authentication saja tidak memisahkan kedua kasus tersebut. Ambient credential dapat ikut terkirim sesuai aturan cookie dan credential, sedangkan server biasanya baru melihat HTTP message setelah browser membuat keputusan kontekstualnya. Fetch Metadata menambahkan request header yang dibuat browser untuk membawa fakta terpilih mengenai konteks tersebut ke policy boundary server.

Keamanan Siber Keamanan Browser

Keamanan Siber / 17 Sep 2026 / 5 min read

Cookie SameSite Menegakkan Batas Site, Bukan Batas Origin

Sebuah aplikasi di https://accounts.example.com memakai session cookie bertanda SameSite=Strict. Service terpisah di https://reports.example.com dikelola tim lain dan memiliki origin berbeda. Kedua host dipisahkan oleh model origin browser untuk banyak kemampuan web, tetapi request dari salah satunya masih dapat diklasifikasikan sebagai same-site terhadap yang lain. Atribut cookie tersebut menegakkan batas site, bukan menduplikasi same-origin policy. Perbedaan ini merupakan inti nilai keamanan SameSite. Atribut tersebut dapat menahan ambient cookie credential pada request yang diklasifikasikan sebagai cross-site, sehingga mengurangi paparan terhadap cross-site request forgery dan attachment credential yang tidak diinginkan. Namun, atribut ini tidak menjadikan setiap sibling hostname sebagai requester eksternal. Deployment yang memperlakukan pemisahan subdomain sebagai trust boundary pada tingkat origin dapat menganggap SameSite memberikan perlindungan lebih besar daripada yang sebenarnya disediakan mekanisme tersebut.

Keamanan Siber HTTP

Keamanan Siber / 16 Sep 2026 / 5 min read

TLS Early Data Menukar Latensi Handshake dengan Risiko Replay

TLS Early Data Menukar Latensi Handshake dengan Risiko Replay Client yang kembali dapat memiliki cukup state dari koneksi TLS 1.3 sebelumnya untuk mengirim application data bersama flight handshake pertamanya. Ini menghilangkan satu round trip dari critical path untuk traffic yang memenuhi syarat, tetapi juga mengubah properti keamanan yang sering dianggap implisit oleh aplikasi: encrypted transport tidak lagi berarti sebuah request hanya dapat muncul satu kali di seluruh koneksi. TLS 1.3 early data, yang umum disebut 0-RTT, dilindungi menggunakan key yang diturunkan dari pre-shared key yang terkait dengan session sebelumnya atau PSK yang disediakan secara eksternal. Server belum memberikan fresh handshake state ketika byte tersebut dikirim. Akibatnya, early data memiliki replay property yang lebih lemah daripada application data biasa yang dikirim setelah handshake.

Keamanan Siber TLS

Rekayasa Perangkat Lunak / 16 Sep 2026 / 6 min read

HTTP Stale-While-Revalidate Memindahkan Refresh Cache dari Request Path

Cache dapat langsung mengembalikan stored response yang sudah expired dan memulai validation secara paralel ketika stale-while-revalidate mengizinkan reuse tersebut. Request yang menemukan stale entry karena itu tidak harus ikut menanggung origin validation latency, tetapi dapat menerima representation data yang lebih lama daripada normal freshness lifetime. Ini adalah pergeseran yang disengaja dalam cache contract. Freshness tetap berakhir pada boundary yang dikonfigurasi. Extension menambahkan interval terpisah tempat stale reuse diizinkan sementara validation berlangsung, sehingga response age dan request latency menjadi sebagian terpisah.

Rekayasa Perangkat Lunak HTTP

Keamanan Siber / 16 Sep 2026 / 8 min read

HTTP Request Smuggling Dimulai Saat Intermediary Berbeda Menentukan Batas Pesan

Reverse proxy menerima request HTTP/1.1, menentukan tempat body berakhir, lalu meneruskan trafik ke application server melalui koneksi persisten. Jika application server menentukan batas berbeda dari informasi framing yang sama, kedua komponen berhenti sepakat mengenai byte mana yang termasuk ke request tertentu. Byte yang dianggap sebagai body oleh satu komponen dapat menjadi awal request baru bagi komponen lain. Perbedaan tersebut merupakan kondisi inti HTTP request smuggling. Masalahnya bukan sekadar header malformed, proxy, atau connection reuse secara terpisah. Masalahnya adalah parser differential di sepanjang chain tempat beberapa recipient menafsirkan framing request dan setidaknya satu koneksi membawa trafik berikutnya.

Keamanan Siber HTTP

Keamanan Siber / 16 Sep 2026 / 8 min read

HTTP Request Framing Desynchronization Mengubah Perbedaan Parser Menjadi Kegagalan Proxy Boundary

HTTP Request Framing Desynchronization Mengubah Perbedaan Parser Menjadi Kegagalan Proxy Boundary Reverse proxy dapat memvalidasi HTTP request, meneruskannya ke origin, tetapi tetap membuat origin memproses urutan request yang berbeda dari yang disetujui proxy. Kegagalan ini bukan akibat hilangnya encryption atau authentication check yang tidak ada. Ia muncul ketika dua recipient mengonsumsi byte pada connection yang sama dengan aturan berbeda untuk menentukan tempat satu message berakhir dan message berikutnya dimulai. HTTP request smuggling adalah konsekuensi keamanan dari ketidaksepakatan tersebut. Boundary penentunya adalah message framing: jika edge server dan downstream server tidak sepakat mengenai body length, field syntax, atau malformed input, byte yang diperlakukan sebagai body data oleh satu komponen dapat ditafsirkan sebagai request baru oleh komponen berikutnya.

Keamanan Siber HTTP

Rekayasa Perangkat Lunak / 16 Sep 2026 / 8 min read

HTTP If-Range Mengikat Pengambilan Parsial pada Identitas Representasi

Client yang hanya memiliki sebagian dari sebuah representasi HTTP menghadapi masalah konsistensi ketika kemudian meminta byte yang belum diterima. Offset byte hanya bermakna terhadap representasi yang byte-nya menjadi dasar offset tersebut. Jika representasi terpilih berubah di antara request, menggabungkan prefix lama dengan suffix baru dapat menghasilkan data yang tidak pernah dikirim server mana pun. If-Range mengikat identitas representasi pada boundary pengambilan parsial tersebut. Ketika validator-nya cocok, server dapat memproses field Range yang menyertainya. Ketika tidak cocok, server mengabaikan Range dan mengirim representasi terpilih secara lengkap melalui jalur response sukses biasa, alih-alih mengembalikan response failed-precondition.

Rekayasa Perangkat Lunak HTTP