Mastering Cyber Security in This Crazy World!

Edisi 1 · RWID · Ecobook Edition

Ditulis oleh Eko Suprapto Wibowo, pendiri Remote Worker Indonesia.

Buku ini tumbuh dari satu peristiwa nyata: sebuah serangan otomatis ke remoteworker.id pada 2 Oktober 2026. Alih-alih menyembunyikannya, kami membukanya dan memakai serangan itu sebagai bahan ajar. Setiap bab berjalan dengan pola yang sama:

teori → cara umum di industri → cara Ecosphere melakukannya → serpihan insiden nyata.

Buku ini bukan ringkasan berita. Ia menjelaskan mengapa sebuah sistem dibangun seperti ini, bukan sekadar apa yang dipasang.

Buku ini bertumbuh. Setiap serangan baru yang masuk ke RWID akan menjadi bab baru pada edisi berikutnya. Membeli buku ini berarti memiliki catatan yang terus bertambah — bukan sekali baca lalu selesai. Semakin banyak yang mencoba menjatuhkan kami, semakin tebal bukunya.

© RWID. Diterbitkan sebagai Ecobook.

Kata Pengantar

RWID (Remote Worker Indonesia) sudah berjalan sejak 2017. Pada 2025 ia viral — dan viralnya dibarengi tuduhan miring dari banyak orang yang tidak mengenalnya: scam. Saya sudah menceritakan sisi manusianya di halaman Welcome aplikasi ini, dan saya tidak akan mengulang semuanya di sini. Yang perlu Anda tahu hanya satu akibatnya: RWID berhenti, lalu setahun kemudian memutuskan kembali.

Saat memutuskan kembali, saya menyusun ulang prioritasnya. Bukan fitur dulu. Bukan tampilan dulu. Keamanan dulu. Alasannya sederhana: tuduhan scam itu, betul atau salah, membuat saya sadar bahwa RWID tidak akan pernah bisa membuktikan apa pun kalau sistemnya roboh begitu diserang. Tahun 2025, saya membangun cepat, memakai banyak layanan pihak ketiga, dan menyesuaikan diri dengan cara yang menurut saya sendiri tidak bisa dipertahankan. Satu di antaranya bikin semua stored procedure RWID hilang. Sejak itu satu prinsip saya pegang: Zero Trust — jangan percaya apa pun yang datang dari internet sampai ia membuktikan dirinya.

Maka ketika RWID kembali pada 2026, saya membangunnya di atas fondasi yang berbeda, dan saya menantang dunia secara terbuka:

Post itu — di Instagram dan Threads — adalah pemicunya. Saya sengaja membuka diri. Serangan yang datang bukan kejutan; ia adalah tamu yang kami undang. Tujuannya satu: membuktikan, secara publik, bahwa sistem ini kuat — dan kalau ternyata belum, kami ingin tahu sekarang, bukan saat jutaan orang sedang menonton.

Buku ini lahir dari undangan itu. Ia menjelaskan teori keamanan yang mendasarinya, arsitektur yang kami bangun, dan serangan nyata yang benar-benar kami tangkis beberapa jam setelah post itu tersebar.

Satu hal yang akan Anda lihat berulang kali: kekuatan kami bukan pada satu tembok besar, melainkan pada cara kami menyusun sistem sehingga satu perbaikan kecil bisa menyebar cepat ke semuanya. Itulah Ecosphere.

— Eko

Cara Membaca Buku Ini

Buku ini ditulis untuk pembangun produk — terutama yang belajar sambil jadi (vibe coder, solo builder, pemula sampai menengah). Tidak ada asumsi bahwa Anda sudah paham keamanan. Yang saya asumsikan: Anda bisa membangun aplikasi web, dan Anda ingin membangunnya dengan standar produksi.

Tiap bab berjalan dengan pola yang sama, dan pola inilah yang membuat buku ini berguna:

1. Teori. Konsep dasarnya, dan alasan di baliknya. Bukan hafalan.
2. Cara umum di industri. Bagaimana dunia biasanya menanganinya.
3. Cara Ecosphere. Bagaimana platform yang kami bangun menerapkannya.
4. Serpihan insiden. Potongan dari serangan nyata 2 Oktober 2026 yang mengilustrasikan poin itu.

Anda bisa membaca berurutan, atau melompat ke bab yang Anda butuhkan. Tanda → menunjuk bacaan lanjutan. Istilah teknis Inggris saya pertahankan bila itu memang istilah bakunya (payload, rate limit, query), agar Anda mengenalinya di dokumentasi mana pun.

Buku ini tidak menggantikan praktik. Di bagian akhir ada Tools: tombol untuk menjalankan simulasi serangan di portal RWID, daftar periksa penyetelan keamanan, dan template laporan ke penyedia layanan internet (ISP).

Daftar Isi

Bagian 1 · Panggung

• 1 · Dunia yang Hidup
• 2 · Sekilas Insiden: satu IP, delapan belas menit
• 3 · Apa Itu Ecosphere (dan mengapa LXS saja tidak cukup)

Bagian 2 · Mengapa Sistem Ini Kuat

• 4 · Akar Teori: Domain-Driven Design & Bounded Context
• 5 · LXS: Linux Services sebagai bata bangunan
• 6 · Gateway & Auth: sumber kekuatan yang memperbaiki cepat

Bagian 3 · Fondasi Keamanan

• 7 · Keamanan adalah Sifat Sistem, bukan Fitur
• 8 · Model Ancaman & Permukaan Serangan
• 9 · Deny-by-Default, Least Privilege, Defense-in-Depth

Bagian 4 · Kelas Serangan & Pertahanan

• 10 · Injeksi & Query Terparameterisasi
• 11 · XSS, Escaping, dan Content Security Policy
• 12 · Sesi & Autentikasi: dari localStorage ke HttpOnly
• 13 · Manajemen Rahasia
• 14 · SSRF, Open-Redirect, dan Validasi URL
• 15 · Abuse: Spam Pendaftaran, Bot, dan Scanner
• 16 · Rantai Pasok Perangkat Lunak

Bagian 5 · Operasi & Skala

• 17 · Tepi: WAF, DDoS, dan Mengapa Origin Hampir Tak Terasa
• 18 · Observability & Alerting: Guard yang Berteriak
• 19 · Incident Response yang Tenang
• 20 · Kesiapan Skala & Kuota

Bagian 6 · Studi Kasus & Alat

• 21 · Studi Kasus: Kronologi Lengkap 2 Oktober 2026
• 22 · Arsitektur Keamanan Ecosphere, dari Ujung ke Ujung
• 23 · Tools: Uji Sistem Anda Sendiri

Buku ini bertumbuh. Setiap serangan baru yang masuk ke RWID akan menjadi bab baru di edisi berikutnya. Membeli buku ini berarti memiliki catatan yang terus diperbarui — bukan sekali baca lalu selesai.

1 · Dunia yang Hidup

Sebelum insiden, sebelum teori, ada satu hal yang perlu Anda lihat dulu. Ini wajah RWID:

Globe itu bukan hiasan. Ia tidak dibuat sembarangan. Ia dirancang sebagai monitor sistem global secara waktu-nyata — satu layar yang menjawab pertanyaan “apa yang sedang terjadi di seluruh dunia RWID?” tanpa harus membuka dasbor teknis.

Apa yang ia pantau

• HQ RWID di Yogyakarta — titik emas yang menandai rumahnya.
• HQ Ecosphere dan node-node-nya — tempat platform berjalan, termasuk node produksi di luar negeri. Kalau sebuah node hidup atau mati, itu terlihat di sini.
• Setiap member — saat seseorang masuk atau mendaftar, muncul denyut di lokasinya, lengkap dengan nama dan kota. Dunia ini bergerak karena penghuninya.
• Detak berkelanjutan — denyut jantung dan sinyal aktivitas yang membuat “dunia” terasa hidup, bukan sekadar peta statis.

Ia sekaligus dua hal: bukti sosial (pengunjung melihat komunitasnya nyata dan aktif) dan monitor operasional (dari mana lalu lintas datang, node mana yang sehat). Satu layar, dua fungsi.

Inilah yang terlihat saat ada serangan

Itu adalah tangkapan globe saat serangan 2 Oktober 2026 berlangsung. Nama-nama asing bermunculan dari satu titik yang sama — Cikarang — beruntun, cepat, dan tidak wajar: deretan tanpa jeda dari kota yang sama, dengan pola yang tak mungkin dilakukan manusia biasa. Dunia yang tadi tenang tiba-tiba ramai dengan satu-satunya sumber.

Dan karena setiap denyut disertai suara, saya tidak perlu sedang menatap layar untuk tahu ada sesuatu yang salah. Telinga menangkap lebih dulu, sebelum mata sempat membaca. Begitu bunyi itu datang beruntun, refleksnya satu: buka globe, dan di sana sudah jelas.

Itulah nilai sebenarnya dari sebuah monitor: bukan sekadar menampilkan data, tetapi membuat yang salah terlihat dan terdengar — mustahil untuk dilewatkan.

Globe bukan satu-satunya yang berteriak. Di kanal Telegram, bot kami mengirim peringatan yang sama — otomatis, dari guard yang memantau tepi:

Dua sinyal datang hampir bersamaan: mata (globe) dan mesin (Telegram). Itu bukan kebetulan. Sistem memang dirancang untuk memberi tahu dari lebih dari satu arah — supaya satu kejadian yang luput dari pandangan tetap tertangkap di tempat lain. Deteksi yang baik tidak bergantung pada satu indra.

Mengapa ini penting untuk sebuah buku keamanan

Karena justru di sinilah keanehan itu terlihat. Ketika sebuah sistem dimonitor sebagai satu dunia yang hidup, hal yang tidak wajar menjadi kentara — nama yang aneh, denyut yang tidak pada tempatnya. Bukan karena ada yang membaca log jam tiga pagi, melainkan karena dunia itu sendiri menunjukkan bahwa ada sesuatu yang salah.

Monitor yang baik tidak hanya menampilkan angka; ia membuat yang salah terasa salah. Globe inilah contoh paling gamblang dari prinsip itu, dan insiden yang kita bahas mulai Bab 2 adalah buktinya.

→ Bab 2 · Sekilas Insiden.

2 · Sekilas Insiden: satu IP, delapan belas menit

Sebelum masuk ke teori, mari lihat dulu apa yang sebenarnya terjadi. Ini potongan yang sudah kami terbitkan sebagai catatan rekayasa di dokumentasi Ecosphere, disederhanakan untuk pembaca buku ini.

Pada 2 Oktober 2026, sekitar pukul 18:16–18:37 WIB, satu alamat IP di Cikarang, Jawa Barat, menjalankan scanner kerentanan otomatis terhadap remoteworker.id. Dalam rentang itu, tepi kami (Cloudflare) memblokir 397 permintaan. Scanner itu menyasar endpoint masuk dan daftar (/signin, /signup, /api/auth/register), mengirim probe injeksi, dan memindai jalur-celah WordPress yang sudah puluhan tahun dikenal.

Yang penting bukan angkanya. Yang penting adalah apa yang tidak terjadi:

• Tidak ada satu pun data yang bocor.
• Pemroses (CPU) server produksi tetap di bawah beban normal; host nyaris tidak berkedip.
• Tidak ada satu pun akun sampah yang bisa masuk, karena email verification wajib.
• Server lama kami bahkan tidak pernah melihat mayoritas permintaan itu, karena semuanya ditolak di tepi.

Satu-satunya jejak yang sempat lolos: 43 akun sampah yang mendaftar dari IP itu. Semuanya kami hapus; 30 pendaftar asli tetap utuh.

Pelajaran pertama: serangan yang berhasil membuat Anda lebih kuat bukan serangan yang gagal, melainkan serangan yang terdeteksi, ditahan, dan dilaporkan dengan bukti.

Insiden ini bukan kejutan. Ia adalah jawaban atas tantangan yang kami sebarkan sendiri. Sisa buku ini menjelaskan mengapa sistemnya bisa setenang itu, dan apa yang bisa Anda tiru untuk sistem Anda.

→ Lanjut ke Bab 3 · Apa Itu Ecosphere untuk memahami fondasi yang membuat semua ini mungkin.

3 · Apa Itu Ecosphere (dan mengapa LXS saja tidak cukup)

Menjelaskan “LXS” tanpa menjelaskan Ecosphere adalah seperti menjelaskan bata tanpa menjelaskan bangunan. Jadi kita mulai dari bangunannya.

Masalah yang ingin dijawab

Cara standar membangun aplikasi di tahun 2020-an menumpuk lapisan: aplikasi dibungkus container, container diorkestrasi Kubernetes, ditambah service mesh, message broker, dan sederet layanan terkelola. Untuk tim besar, itu wajar. Untuk satu orang yang membangun produk, itu beban: setiap lapisan menambah permukaan yang bisa salah, dan — yang lebih penting untuk buku ini — permukaan yang bisa diserang.

Ecosphere mengambil arah lain. Ia menganggap aplikasi sebagai kumpulan kapabilitas kecil yang saling melengkapi, bukan satu monolit raksasa maupun kumpulan container yang tak terhitung.

Istilah-istilah intinya

• Domain. Satu tanggung jawab yang jelas dan mandiri — identitas, artikel, dompet, notifikasi. Tiap domain punya datanya sendiri dan berbicara lewat kontrak, bukan lewat import kode satu sama lain.
• LXS (Linux Services). Cara sebuah domain dikemas menjadi satu biner siap-jalan dengan kontrak yang tegas: variabel yang dibutuhkan, port, memori, dan rute mana yang ia buka. Detailnya di Bab 5.
• Estate. Rangkaian LXS + kode inti (domain core) yang membentuk satu aplikasi utuh. remoteworker.id adalah sebuah estate.
• Registry. Katalog LXS berversi. Anda memakai ulang kapabilitas yang sudah teruji alih-alih menulis ulang.

Mengapa ini penting untuk keamanan

Satu kalimat: satu kapabilitas di satu tempat berarti satu tempat untuk memperbaiki. Kalau ada kelemahan di LXS autentikasi, Anda perbaiki sekali, terbitkan versi baru, dan semua estate yang memakainya bisa naik versi. Anda tidak memperbaiki kode login yang tersalin di sepuluh proyek.

Itulah yang kami sebut kekuatan yang terpropagasi: perbaikan cepat di satu titik menyebar ke seluruh sistem, bukan tertinggal di satu aplikasi.

Coba sendiri

Ecosphere bukan teori yang terkunci di buku ini. Platformnya terbuka untuk dicoba — mulai dari instalasi, dokumentasi, sampai komposisi aplikasi pertama Anda:

→ https://getecosphere.com

Semakin banyak orang membangun di atasnya, semakin banyak yang ikut memperkuat fondasi yang sama. Itu bagian dari niatnya: keamanan yang dibagikan, bukan dipelihara sendiri-sendiri.

Di bab berikutnya kita gali dua akar teorinya — Domain-Driven Design dan konsep LXS itu sendiri — sebelum masuk ke bab yang paling penting bagi kekuatan kami: Gateway dan Auth.

4 · Akar Teori: Domain-Driven Design & Bounded Context

Sebelum ada LXS, ada idenya lebih dulu: Domain-Driven Design (DDD). Buku ini tidak akan mengajarkan DDD secara utuh, tetapi satu konsepnya perlu Anda pahami, karena dari situlah keamanan kami bertumpu.

Bounded context: satu kata, satu makna

Bayangkan kata “user”. Di domain identitas, user berarti akun dengan kata sandi dan sesi. Di domain artikel, user hanyalah penulis. Di domain dompet, user adalah pemilik saldo. Kalau Anda memaksa satu definisi “user” untuk semuanya, kode Anda pelan-pelan jadi saling tergantung, dan tiap perubahan menyentuh segalanya.

Bounded context adalah jawabannya: tetapkan batas yang jelas. Setiap konteks punya modelnya sendiri, datanya sendiri, dan kontraknya sendiri. Mereka tidak saling meminjam tipe data.

Aturan yang mengikat (dan mengapa ini soal keamanan)

Sistem yang dibangun di atas batas tegas punya sifat yang berharga untuk keamanan:

1. Tanpa impor antar-domain. Sebuah domain berkomunikasi dengan domain lain melalui kontrak publik (biasanya HTTP), bukan dengan memanggil fungsi internalnya. Artinya permukaan serangan sebuah domain tertutup rapi: yang bisa memanggilnya hanya lewat pintu yang dideklarasikan.
2. Penyimpanan terpisah. Tiap domain punya basis datanya sendiri. Kerentanan di satu domain tidak otomatis membuka seluruh basis data. Blast radius kecil.
3. Referensi, bukan salinan. Domain menyimpan rujukan ke data milik domain lain (sebuah ID), bukan salinannya. Tidak ada data yang berganda dan tidak konsisten di banyak tempat.
4. Identitas eksplisit di batas. Operasi tulis tidak menyimpulkan pemilik dari token secara diam-diam; ia meminta bukti yang eksplisit.

Ringkasnya: pembatasan yang jelas adalah kontrol keamanan. Ketika sebuah komponen hanya bisa dijangkau lewat satu pintu yang dideklarasikan, memikirkan keamanannya jauh lebih mudah daripada kode yang saling terhubung ke mana-mana.

Dari konsep ke biner

DDD menjelaskan bagaimana memikirkan batas. Ia tidak menjelaskan bagaimana mengemas batas itu menjadi sesuatu yang bisa dijalankan dan dikomposisi dengan aman. Untuk itu kita butuh LXS — bahasan bab berikutnya.

→ Bab 5 · LXS: Linux Services sebagai bata bangunan.

5 · LXS: Linux Services sebagai bata bangunan

LXS adalah cara sebuah domain dikemas menjadi satu biner yang siap-jalan, lengkap dengan kontrak yang bisa dibaca mesin maupun manusia. Ia dijalankan native di dalam LXC — tanpa lapisan virtualisasi berat, tanpa image container yang menumpuk.

Apa isi kontrak sebuah LXS

Setiap LXS mendeklarasikan dirinya secara terbuka:

• Variabel lingkungan yang ia butuhkan (serta mana yang berupa rahasia).
• Port yang ia duduki.
• Sumber daya (memori, disk) yang ia minta.
• Rute yang ia buka — dan pada tingkat akses apa (public, auth, role:...).
• Jaringan: masuk dari mana, keluar ke mana.

Kontrak ini bukan dokumentasi pasif. Pada saat deploy, platform memeriksa apakah estate benar-benar memberikan apa yang diminta — dan menolak komposisi yang tidak cocok. Sebuah LXS tidak bisa diam-diam mengakses sesuatu yang tidak ia deklarasikan.

Versi yang tak berubah

LXS diterbitkan dalam versi yang immutable: [email protected] berarti tepat biner itu. Anda tidak mengubah versi yang sudah terbit; Anda memperbaiki dengan menerbitkan versi baru. Akibatnya, memperbaiki kelemahan menjadi tindakan yang tegas dan bisa ditelusuri: satu versi baru, satu catatan perubahan, satu keputusan untuk naik versi di estate yang terdampak.

Satu domain, satu biner

Aturan “satu LXS = satu domain” menjaga biner tetap kecil dan fokus. Permukaan serangannya pun kecil: proses ini tidak membawa kemampuan yang tidak ia butuhkan. Tidak ada interpreter besar, tidak ada kerangka kerja serbaguna; hanya apa yang perlu.

Kapabilitas bersama, bukan salinan

Ini inti seluruh buku: Login, notifikasi, penyimpanan, artikel — semuanya adalah kapabilitas yang sama di hampir setiap aplikasi. Kami tidak menyalinnya ke tiap proyek; kami menerbitkannya sekali sebagai LXS, lalu memakainya berulang. Ketika ada masalah keamanan di salah satunya, perbaikannya tidak perlu diulang di sepuluh tempat.

Ada dua LXS yang paling menentukan kekuatan kami. Keduanya dibahas di bab berikutnya.

→ Bab 6 · Gateway & Auth: sumber kekuatan.

6 · Gateway & Auth: sumber kekuatan yang memperbaiki cepat

Kalau buku ini punya satu bab yang paling ingin saya Anda ingat, ini babnya.

Di banyak sistem, keamanan disebar: tiap layanan menjaga dirinya sendiri, menyalin logika login, dan punya tafsir sendiri soal siapa yang boleh masuk. Hasilnya bisa ditebak: tidak konsisten, sulit diaudit, dan memperbaiki satu kelemahan berarti menyentuh banyak tempat.

Kami melakukannya sebaliknya. Dua LXS memegang hampir semua keputusan keamanan, dan keduanya terpasang di depan setiap estate.

Gateway: pintu depan yang menolak secara bawaan

Gateway adalah satu-satunya pintu masuk dari internet ke layanan estate. Ia bekerja deny-by-default: sebuah rute hanya bisa dilewati kalau estate menuliskannya secara eksplisit, beserta tingkat aksesnya (public, auth, role:superadmin). Tidak ada “forward semuanya”. Tidak ada jalan pintas.

Konsekuensinya:

• Layanan internal tidak perlu (dan tidak boleh) diekspos langsung. Hanya pintu depan yang bicara dengan dunia luar.
• Setiap permintaan diperiksa satu kali di satu tempat. Kalau ada aturan baru atau kelemahan pada logika akses, diperbaiki di gateway, semua estate mendapatkannya.
• Saat belajar dari insiden seperti 2 Oktober, kami menambahkan aturan hanya di satu titik — dan seluruh estate seketika ikut aman.

Auth: satu otoritas identitas

Auth adalah LXS yang memegang identitas: kata sandi, sesi, token, peran. Ia juga bisa berperan sebagai penyedia identitas (OIDC) sehingga beberapa aplikasi bisa berbagi satu akun. Karena semua estate memakai Auth yang sama, model sesinya pun seragam — dan itu penting, karena sebagian besar serangan web menyerang sesi.

Salah satu keputusan yang paling berdampak adalah memindahkan sesi dari localStorage ke cookie HttpOnly. Cookie HttpOnly tidak bisa dibaca oleh skrip apa pun di halaman, sehingga satu celah XSS tidak otomatis berarti pencurian sesi. Perubahan ini pun dikerjakan sekali di Auth, lalu berlaku di semua estate yang memakainya. (Kisah lengkapnya ada di Bab 12.)

Mengapa ini “kekuatan yang terpropagasi”

Bayangkan tiga dunia:

• Dunia salinan. Login disalin di 10 aplikasi. Kelemahan sesi ditemukan. Anda memperbaiki 10 tempat. Beberapa terlewat. Yang terlewat tetap rapuh selama berbulan-bulan.
• Dunia monolit. Satu perbaikan menjangkau semuanya — tetapi hanya aplikasi itu. Aplikasi lain tetap punya masalahnya sendiri.
• Dunia LXS. Auth diperbaiki sekali, dinaikkan versinya, dan semua estate yang mengomposisinya bisa naik versi. Satu perbaikan, jangkauan luas, tercatat.

Itulah mengapa saya menyebut gateway dan auth sebagai sumber kekuatan kami. Bukan karena keduanya sempurna, tetapi karena keduanya membuat kami bisa bergerak cepat saat ketidaksempurnaan itu ketahuan — dan itu jauh lebih penting daripada klaim “aman” yang tidak bisa dibuktikan.

Serpihan insiden

Ketika scanner 2 Oktober menembak rute-rute masuk, bukan tiap layanan yang menahan. Gateway-lah yang menolak mayoritas, dan Auth yang memastikan firewall pendaftaran (verifikasi email) tetap utuh. Kami tidak perlu menyentuh dua puluh komponen; cukup satu pintu dan satu otoritas.

→ Sampai di sini fondasi konseptualnya. Bagian 3 mulai dari prinsip keamanan yang berlaku untuk sistem apa pun, LXS maupun bukan.