Tiga tahun yang lalu, saya melihat sebuah startup yang saya bantu kehilangan segalanya dalam 72 jam. Bukan karena serangan dari negara yang canggih atau eksploitasi zero-day yang menjadi berita utama. Mereka kehilangan seluruh basis data pelanggan mereka, reputasi mereka, dan akhirnya bisnis mereka karena satu kerentanan injeksi SQL yang diperkenalkan oleh seorang pengembang junior selama penerapan mendesak pada hari Jumat. Serangan itu terjadi pada pagi hari Senin. Pada Rabu sore, mereka sedang menyusun dokumen kebangkrutan.
💡 Poin Utama
- Perangkap Otentikasi yang Menangkap Semua
- Cross-Site Scripting: Kerentanan yang Tidak Pernah Mati
- SQL Injection: Kerentanan Kuno yang Masih Berfungsi
- HTTPS Tidak Lagi Opsional
Saya Sarah Chen, dan saya telah menghabiskan 12 tahun terakhir sebagai arsitek keamanan di perusahaan-perusahaan mulai dari startup yang berjuang hingga perusahaan Fortune 500. Saya telah melihat kesalahan yang sama yang dapat dicegah menghancurkan bisnis berulang kali. Bagian yang membuat frustrasi? Kebanyakan bencana ini bisa dihindari dengan pengetahuan keamanan dasar yang memerlukan waktu lebih sedikit untuk dipelajari daripada kerangka kerja JavaScript rata-rata Anda.
Berikut adalah apa yang tidak diberitahukan orang ketika Anda belajar mengkode: keamanan bukanlah topik lanjutan yang Anda hadapi setelah menguasai segalanya. Ini adalah dasar. Ini seperti belajar mengemudi tanpa memahami bahwa lampu merah berarti berhenti. Anda mungkin bisa lolos untuk sementara waktu, tetapi pada akhirnya, Anda akan menyebabkan kecelakaan yang bencana.
Menurut Laporan Investigasi Pelanggaran Data Verizon 2023, 74% pelanggaran melibatkan elemen manusia, termasuk kesalahan, penyalahgunaan, atau rekayasa sosial. Tetapi inilah yang mengejutkan: ketika mereka menganalisis serangan aplikasi web secara spesifik, mereka menemukan bahwa 86% mengeksploitasi kerentanan yang telah didokumentasikan dan dapat dicegah selama lebih dari satu dekade. Kita tidak kalah dari penyerang yang canggih. Kita kalah karena ketidaktahuan kita tentang dasar-dasar.
Perangkap Otentikasi yang Menangkap Semua
Izinkan saya memberi tahu Anda tentang otentikasi, karena di sinilah saya melihat pengembang membuat kesalahan kritis pertama mereka. Mereka memperlakukannya seperti fitur kotak centang daripada dasar dari seluruh model keamanan mereka. Saya pernah meninjau kode di mana seorang pengembang menerapkan otentikasi dengan memeriksa apakah email pengguna ada di dalam cookie. Bukan cookie yang ditandatangani. Bukan token yang dienkripsi. Hanya alamat email teks biasa yang bisa dimodifikasi oleh siapa pun dalam alat pengembang di browser mereka.
Ketika saya menunjukkan hal ini, pengembang itu berkata, "Tapi ini berfungsi!" Dan itulah masalahnya. Kerentanan keamanan tidak mengumumkan dirinya dengan pesan kesalahan. Mereka berfungsi dengan sempurna hingga seseorang mengeksploitasinya.
Inilah yang sebenarnya diperlukan untuk otentikasi yang tepat. Pertama, Anda perlu memahami perbedaan antara otentikasi (membuktikan siapa Anda) dan otorisasi (membuktikan apa yang Anda diizinkan untuk lakukan). Saya telah melihat sistem produksi di mana konsep ini begitu kabur sehingga memperbaiki satu masalah keamanan menciptakan tiga masalah lainnya.
Penyimpanan kata sandi adalah hal yang tidak bisa dinegosiasikan. Anda harus menggunakan algoritma hashing kata sandi yang tepat seperti bcrypt, scrypt, atau Argon2. Bukan SHA-256. Bukan MD5. Pastinya bukan teks biasa. Saya masih menjumpai basis data di tahun 2026 di mana kata sandi disimpan dalam teks biasa, dan setiap kali, pengembang memberitahu saya bahwa mereka "tidak berpikir siapa pun benar-benar akan mencoba meretas mereka." Itu seperti meninggalkan pintu depan Anda tidak terkunci karena Anda tidak berpikir siapa pun sebenarnya akan merampok Anda.
Angka-angka di sini sangat mencolok. Menurut laporan Pusat Sumber Daya Pencurian Identitas 2023, ada 3.205 kompromi data yang mempengaruhi lebih dari 353 juta korban di Amerika Serikat saja. Ketika peneliti menganalisis data yang bocor, mereka menemukan bahwa dalam kasus di mana metode penyimpanan kata sandi diungkapkan, 43% menggunakan hashing yang tidak memadai atau tidak ada hashing sama sekali.
Manajemen sesi adalah di mana hal-hal menjadi menarik. Anda perlu menghasilkan token sesi acak yang aman secara kriptografi. Generator angka acak bawaan di sebagian besar bahasa pemrograman tidak aman secara kriptografi. Di Node.js, Anda ingin menggunakan crypto.randomBytes(), bukan Math.random(). Di Python, Anda ingin menggunakan secrets.token_hex(), bukan random.random(). Saya telah melihat token sesi dihasilkan dengan timestamp dan ID pengguna yang digabungkan bersama. Seorang penyerang dapat memprediksi itu dalam beberapa detik.
Token sesi Anda harus memiliki setidaknya 128 bit entropi. Mereka harus ditransmisikan hanya melalui HTTPS. Mereka harus memiliki flag HttpOnly yang diatur sehingga JavaScript tidak dapat mengaksesnya. Mereka harus memiliki flag Secure yang diatur sehingga mereka tidak pernah dikirim melalui koneksi yang tidak terenkripsi. Mereka harus memiliki atribut SameSite yang diatur untuk mencegah serangan CSRF. Dan mereka harus kedaluwarsa. Saya merekomendasikan 30 menit ketidakaktifan untuk aplikasi sensitif, mungkin 24 jam untuk skenario risiko lebih rendah.
Cross-Site Scripting: Kerentanan yang Tidak Pernah Mati
Serangan XSS seperti kecoa. Mereka telah ada selamanya, semua orang tahu tentang mereka, dan yet mereka terus muncul dalam kode produksi. OWASP Top 10 telah menyertakan kerentanan XSS sejak awal berdirinya pada tahun 2003, dan itu masih ada pada tahun 2026. Itu adalah 21 tahun dari kerentanan yang sama yang bisa dicegah.
"Keamanan bukanlah topik lanjutan yang Anda hadapi setelah menguasai segalanya. Ini adalah dasar. Ini seperti belajar mengemudi tanpa memahami bahwa lampu merah berarti berhenti."
Saya ingat mengaudit aplikasi kesehatan yang menampilkan catatan pasien yang dimasukkan oleh dokter. Para pengembang telah membangun editor teks kaya yang memungkinkan pemformatan dasar. Kedengarannya masuk akal, kan? Kecuali mereka mengambil input HTML itu dan merendernya langsung di halaman tanpa sanitasi apa pun. Saya mendemonstrasikan kerentanannya dengan memasukkan catatan pasien yang berisi tag skrip. Skrip itu dapat mencuri token sesi, memodifikasi catatan medis, atau mengekstrak data pasien. Para pengembang terkejut. Mereka tidak pernah mempertimbangkan bahwa seorang dokter mungkin berniat jahat, atau bahwa komputer seorang dokter yang terinfeksi mungkin menyuntikkan kode berbahaya.
Inilah prinsip dasar: jangan pernah mempercayai input pengguna. Selamanya. Bukan dari dokter, bukan dari administrator, bukan dari CEO Anda. Setiap potongan data yang berasal dari luar aplikasi Anda berpotensi berbahaya hingga terbukti sebaliknya.
Ada tiga jenis XSS yang perlu Anda pahami. Stored XSS adalah ketika kode berbahaya disimpan di basis data Anda dan dieksekusi setiap kali seseorang melihat data itu. Reflected XSS adalah ketika kode berbahaya dalam parameter URL langsung dipantulkan kembali dalam respons. DOM-based XSS adalah ketika JavaScript sisi klien mengambil input pengguna dan menyisipkannya ke dalam halaman tanpa sanitasi yang tepat.
Solusinya tidak rumit, tetapi memerlukan disiplin. Anda perlu meloloskan output berdasarkan konteks. Jika Anda menyisipkan data ke dalam konten HTML, Anda perlu menggunakan pengkodean entitas HTML. Jika Anda menyisipkan data ke dalam string JavaScript, Anda perlu menggunakan pelarian JavaScript. Jika Anda menyisipkan data ke dalam URL, Anda perlu menggunakan pengkodean URL. Jika Anda menyisipkan data ke dalam CSS, Anda perlu menggunakan pelarian CSS.
Kerangka kerja modern membantu dalam hal ini. React, Vue, dan Angular semuanya meloloskan output secara default. Tetapi mereka bukan sihir. Jika Anda menggunakan dangerouslySetInnerHTML di React atau v-html di Vue, Anda melewati perlindungan tersebut. Saya telah melihat pengembang menggunakan fitur-fitur ini karena mereka "membutuhkan" untuk merender HTML, tanpa memahami bahwa mereka membuka kerentanan XSS.
Kebijakan Keamanan Konten adalah garis pertahanan kedua Anda. CSP adalah header HTTP yang memberi tahu browser tentang sumber konten mana yang sah. Anda dapat memblokir skrip inline sepenuhnya, membatasi domain mana yang dapat memuat JavaScript, dan mencegah seluruh kelas serangan XSS. Menurut penelitian Google, menerapkan CSP yang ketat dapat mencegah sekitar 95% serangan XSS. Namun, dalam pengalaman saya, kurang dari 30% aplikasi yang saya audit memiliki CSP sama sekali, dan sebagian besar dari itu terlalu permisif sehingga pada dasarnya tidak berguna.
SQL Injection: Kerentanan Kuno yang Masih Berfungsi
SQL injection seharusnya sudah punah. Ini telah dipahami dengan baik sejak tahun 1990-an. Bobby Tables telah menjadi meme selama lebih dari satu dekade. Namun, menurut laporan Akamai 2023 tentang Keadaan Internet, upaya injeksi SQL menyumbang 65% dari semua serangan aplikasi web. Mengapa? Karena itu masih berfungsi.
| Tipe Kerentanan | Tingkat Risiko | Kesulitan Pencegahan | Penyebab Umum |
|---|---|---|---|
| SQL Injection | Kritis | Mudah | Input pengguna yang tidak disanitasi dalam query |
| Otentikasi Lemah | Kritis | Mudah | Kebijakan kata sandi yang buruk, tidak ada MFA |
| XSS (Cross-Site Scripting) | Tinggi | Sedang | Konten pengguna yang tidak meloloskan dalam HTML |
| Kontrol Akses yang Rusak | Tinggi | Sedang | Pemeriksaan otorisasi yang hilang |
| Kesalahan Konfigurasi Keamanan | Sedang | Mudah | Pengaturan default, endpoint yang terekspos |
Saya pernah memberikan konsultasi untuk sebuah perusahaan e-commerce yang telah beroperasi selama delapan tahun. Mereka telah memproses jutaan transaksi. Mereka memiliki tim berisi 15 pengembang. Dan fungsionalitas pencarian mereka rentan terhadap injeksi SQL. Kode-nya terlihat seperti ini: mereka mengambil istilah pencarian dari parameter URL dan menggabungkannya langsung ke dalam query SQL. Tanpa parameterisasi. Tanpa validasi input. Tidak ada.
Ketika saya mendemonstrasikan kerentanannya,