Ribet Sih, Tapi ...

Bayangin saat mau mudik. Mastiin tabung gas, mastiin regulator kompor, mastiin pintu-pintu, mastiin jendela-jendela, mastiin CCTV, mastiin colokan listrik, kendaraan dikunci ganda, mastiin air, mastiin gembok, dan mastiin banyak hal deh pokonya. Ampe kadang-kadang titip pesan ke tetangga buat sesekali diliatin.

Ribet banget ya. Tapi semua itu dilakuin supaya bisa mudik dengan hati tenang, kan.

Nah, Di development, semua yang berbau “ribet” cenderung dianggap beban yang setara, padahal resikonya jelas jelas nggak setara. Setup validasi input buat form komentar publik itu beda level resiko dengan setup validasi input buat endpoint yang nyimpen data payment. Tapi keduanya sering diperlakukan sama, dikeluhin sama sama ribet, kadang malah dua duanya di-skip dengan alasan yang sama: “ribet amat, ntar aja deh”.

Danger

Daripada ribet setelah terjadi insiden, mending ribet sekarang kan!!

Yaa, Ribet, Tapi … (Isi Sendiri)

Persis seperti persiapan sebelum mudik, ribetnya security itu ada alasannya. Di software engineering, ada distinction lama yang relevan banget di sini. Istilahnya essential complexity dan accidental complexity, dari tulisan klasik Fred Brooks soal kenapa nggak ada “silver bullet” di software engineering.

Essential complexity itu kompleksitas yang muncul karena masalahnya sendiri memang begitu. Nggak bisa dihindari, cuma bisa dikelola. Accidental complexity itu kompleksitas yang muncul karena cara kita nyelesaiin masalahnya, bukan karena masalahnya. Ini yang biasanya bisa disederhanain, dan memang seharusnya disederhanain sih.

Prinsip “mulai dari kompleksitas paling rendah” itu tetap valid kok. Cuma kuncinya sih kita perlu tahu “is it the real problem?”. Ngunci pintu sebelum mudik itu ribet karena dia ngejawab “is it the real problem?”: rumah ini bakal kosong berapa lama, dan apa yang bisa terjadi selama itu.

Setup CORS dan whitelist domain yang benar juga ribet karena ngejawab “is it the real problem?”: origin mana yang seharusnya boleh manggil endpoint ini, dan apa yang bisa terjadi kalau sembarang origin boleh masuk.

Kalau ada yang bilang “ribet amat, ntar aja deh”, risiko nya masih ada, siap-siap aja nanggung akibatnya nanti. Syukur kamu yang nanggung, yang kasian kan klo orang lain yang nanggung, apalagi kalo mereka nggak tau konteksnya.

Essential Complexity Bukan Alasan Buat Overengineering

Ini bukan pembenaran buat bikin semua hal serumit mungkin atas nama security. Threat yang nggak nyata tetap accidental complexity, walau dibungkus istilah security. Sama seperti nggak semua orang perlu pasang CCTV cuma buat ditinggal belanja sejam. Bedanya bukan ribet vs simple, tapi ribet yang perlu vs ribet yang percuma. Kalau kamu nggak bisa jawab pertanyaan “resiko nyata apa yang perlu diselesaiakan”, kemungkinan besar itu accidental complexity yang menyamar jadi security.

Contoh yang mungkin Ribet, tapi sebenarnya ngejawab resiko nyata

CORS dan whitelist domain itu contoh favorit buat topik ini, karena hampir semua developer pernah ngerasain godaan buat skip keduanya, terutama pas lagi buru buru deliver sesuatu.

Alurnya biasanya begini. Awalnya cuma testing lokal, jadi Access-Control-Allow-Origin diset ke * biar nggak perlu mikirin origin sama sekali. Rencananya nanti diperketat sebelum production. Tapi “nanti” itu keburu ketiban prioritas lain, dan wildcard itu ikut ke-deploy. Nggak ada yang notice, karena aplikasinya tetap jalan normal dari sisi user. Rasa ribet buat setup whitelist domain yang benar udah keburu dianggap selesai duluan, padahal cuma ditunda.

Konsekuensinya nggak langsung keliatan. Nggak ada alarm yang bunyi. Yang keliatan cuma di titik lain, entah pas security audit, pas pentest, atau pas ada orang lain yang review dan nanya “ini kenapa origin-nya bebas begini”. Dan begitu ditanya, jawabannya sering “oh iya, itu harusnya udah diperketat dari kemarin”. Cost buat benerinnya sekarang jauh lebih besar dari cost buat setup yang benar dari awal, karena sekarang harus audit ulang semua endpoint yang kena, mikirin breaking changes buat consumer yang mungkin udah kebiasaan manggil bebas, dan jelasin ke tim kenapa ini bisa kelewat.

Bandingin dengan cost kalau dari awal langsung setup whitelist domain yang jelas. Effortnya kecil, biasanya cuma nulis daftar origin yang memang seharusnya boleh akses, dan itu keputusan yang bisa diambil begitu kamu tau siapa consumer dari API-mu. Ribetnya nyata, tapi predictable dan selesai sekali di awal. Bukan seperti nggak ngunci pintu terus berharap nggak kenapa napa selama ditinggal seminggu.

Ngecek Diri Sendiri Sebelum Skip

Kalau lain kali kamu nemu diri lagi mikir “ribet, tapi ya udahlah, skip aja”, ini beberapa pertanyaan yang bisa langsung kamu tes ke diri sendiri yaa

1. Ribet sih, tapi ini beresin resiko apa? Kalau kamu nggak bisa jawab dalam satu kalimat, kemungkinan ini accidental complexity yang perlu disederhanain beneran, bukan diributin.

2. Kalau ini di-skip, siapa yang bakal nanggung akibatnya? Kalau jawabannya “orang lain, di masa depan, yang belum tentu tau konteks sekarang”, itu tanda kamu lagi mindahin resiko, bukan ngilangin resiko.

3. Effort buat implementasinya beneran ribet ga si, atau cuma keliatan ribet aja? atau ya perlu dibiasaain aja Sama seperti checklist sebelum mudik, begitu udah jadi kebiasaan, ribetnya nggak kerasa lagi.

4. Kalau ada yang audit kerjaan ini bulan depan, apa kamu bisa jelasin kenapa ini di-skip dengan alasan yang masuk akal ke orang lain, bukan cuma masuk akal ke diri sendiri?

Kalau semua jawabannya ternyata “bisa disederhanain kok, resikonya kecil, dan aku bisa jelasin kenapa”, ya lanjut, itu keputusan yang valid. Tapi kalau jawabannya lebih ke “males aja” atau “belum pernah kejadian”, itu tandanya kamu lagi pakai rasa ribet buat ngindarin pertanyaan yang lebih penting. Sama seperti rumah yang ditinggal mudik, bukan soal seberapa ribet persiapannya, tapi seberapa besar resiko yang lagi kamu tinggalin.

PRINSIP UTAMA:

Meski memang harus Ribet, tapi sebanding sama resikonya, Lebih Baik Dilakukan saja