Seorang developer meluncurkan aplikasi SaaS. Tiga hari kemudian, database-nya dijebol karena SQL injection yang tidak diantisipasi. 12.000 data pengguna bocor — dan aplikasi yang dibangun selama 6 bulan harus dihapus dalam semalam. Inilah 7 langkah keamanan yang harus dilakukan SEBELUM kamu menekan tombol publish.
Hari Kamis jam 02.30 pagi, Aryo membuka laptopnya dengan mata sembab. Aplikasi SaaS yang ia bangun selama 6 bulan baru tayang hari Senin. Total 47 pengguna — teman kuliah, saudara, dan beberapa orang dari forum startup. Data mereka: nama, email, nomor telepon, dan alamat.
Tapi seseorang di forum hacker menemukan celah. SQL injection sederhana di endpoint pencarian. Satu curl request, dan 12.000 baris data pengguna mengalir keluar dari database seperti air dari tangki bocor.
“Bapak/Ibu, tolong maafkan saya. Data Anda bocor karena kelalaian saya. Saya tidak punya tim keamanan. Saya hanya seorang solo developer yang terlalu fokus pada fitur.” — itu adalah pesan WhatsApp terakhir yang dikirim Aryo ke setiap penggunanya sebelum menutup aplikasi untuk selama-lamanya.
Kisah Aryo bukan fiksi. Ini terjadi setiap minggu di Indonesia. Startup yang baru lahir mati di hari ketiga karena keamanan yang tidak terpikirkan. Dan yang menyedihkan: sebagian besar celah ini bisa dicegah dengan 7 langkah sederhana yang masing-masing tidak memakan waktu lebih dari 30 menit.
Berikut 7 langkah wajib yang harus kamu lakukan SEBELUM meluncurkan aplikasi — bahkan jika kamu solo developer tanpa tim keamanan.
Langkah 1: HTTPS Wajib — Bukan Opsional
Ini langkah paling dasar, tapi masih sering dilewatkan. Banyak developer menggunakan HTTP saja saat tahap development dan “lupa” mengaktifkan HTTPS saat deploy ke production.
Mengapa penting: Tanpa HTTPS, semua data yang dikirim antara browser pengguna dan server kamu — termasuk password, token, data pribadi — dikirim dalam bentuk teks mentah (plaintext). Siapa pun di jaringan yang sama (WiFi kafe, WiFi kampus) bisa membaca data tersebut dengan tool sederhana seperti Wireshark.
Cara melakukannya: Gunakan Let’s Encrypt (SSL/TLS gratis dengan Certbot) atau Cloudflare. Keduanya gratis. Cloudflare bahkan menyediakan HTTPS otomatis dengan satu klik.
Waktu yang dibutuhkan: 15 menit.
Langkah 2: Input Validation — Jangan Percaya Apa Pun dari Pengguna
Aturan nomor satu dalam keamanan aplikasi: never trust user input. Setiap data yang masuk dari browser pengguna adalah potensi senjata — termasuk data yang sudah kamu validasi di frontend.
Mengapa penting: SQL injection terjadi karena input pengguna dimasukkan langsung ke query database tanpa sanitasi. Cross-Site Scripting (XSS) terjadi karena input pengguna dirender langsung ke halaman web tanpa encoding. Keduanya adalah celah paling umum di OWASP Top 10.
Cara melakukannya:
- Gunakan prepared statements/parameterized queries untuk semua query database (jangan string concatenation!)
- Validasi input di server-side (jangan hanya andalkan validasi JavaScript di frontend)
- Gunakan whitelist validation — tentukan apa yang BOLEH masuk, bukan hanya apa yang DILARANG
Waktu yang dibutuhkan: 30 menit untuk audit dan perbaikan kode yang sudah ada.
Langkah 3: Password Hashing yang Benar
Jika database kamu bocor — dan pada titik tertentu bisa terjadi — password pengguna harus tetap aman. Menyimpan password dalam bentuk teks mentah (plaintext) adalah pelanggaran serius terhadap kepercayaan pengguna. Bayangkan jika 12.000 password — yang mungkin digunakan ulang di email, bank, dan akun lain — jatuh ke tangan yang salah, bukan hanya aplikasi kamu yang dibobol, tapi juga akun-akun lain yang menggunakan password yang sama.
Cara melakukannya: Gunakan bcrypt, Argon2, atau scrypt untuk hashing password. Jangan gunakan MD5, SHA-1, atau SHA-256 untuk password — mereka terlalu cepat dan bisa di-crack dengan GPU dalam hitungan detik.
Framework populer seperti Laravel (bcrypt default), Django (PBKDF2), dan Spring Security sudah menyediakan hashing yang benar secara default. Pastikan kamu tidak meng-override-nya dengan implementasi manual.
Waktu yang dibutuhkan: 10 menit (cek konfigurasi framework).
Langkah 4: Rate Limiting — Buat Bot Tidak Bisa Menyerang
Rate limiting adalah batasan jumlah request yang bisa dilakukan pengguna (atau IP) dalam periode waktu tertentu. Tanpa rate limiting, endpoint login kamu bisa di-brute force dengan ribuan percobaan per detik. Endpoint API kamu bisa dipukul dengan request berulang yang menghabiskan resource server.
Cara melakukannya: Tambahkan middleware rate limiting di aplikasi kamu. Contoh implementasi: Laravel memiliki throttle middleware built-in. Express.js bisa menggunakan express-rate-limit. Django memiliki django-ratelimit. Untuk API gateway, gunakan tool seperti Kong atau Nginx yang sudah memiliki rate limiting bawaan.
Penting: atur rate limit yang berbeda untuk endpoint publik (lebih longgar) dan endpoint sensitif seperti login, registrasi, dan reset password (lebih ketat — misalnya 5 percobaan per menit).
Waktu yang dibutuhkan: 20 menit.
Langkah 5: Dependency Scanning — Jangan Biarkan Library Usang Mengintai
Aplikasi modern terdiri dari puluhan — bahkan ratusan — library dan dependency. Setiap library adalah potensi pintu masuk untuk hacker. CVE (Common Vulnerabilities and Exposures) baru ditemukan setiap hari di library populer.
Cara melakukannya: Gunakan tool scanning otomatis:
- npm audit (untuk Node.js) — gratis, built-in
- pip-audit (untuk Python) — gratis
- composer audit (untuk PHP/Laravel) — gratis, built-in di Composer 2
- Snyk — gratis untuk open source projects
- Dependabot (GitHub) — gratis, auto-update dependency
- OWASP Dependency-Check — gratis, integrasi CI/CD
Jadwalkan scanning otomatis setiap minggu. Pasang Dependabot di GitHub untuk menerima PR update dependency secara otomatis.
Waktu yang dibutuhkan: 15 menit untuk setup, 5 menit per minggu untuk review.
Langkah 6: Environment Variables — Jangan Hardcode Credential
Ini adalah kesalahan yang paling memalukan tapi paling sering terjadi: hardcode credential di source code dan push ke GitHub. Database password, API key, secret key — semuanya ada di repository publik.
Sebuah studi dari North Carolina State University menemukan bahwa 100.000+ repository GitHub mengandung secret yang valid — termasuk AWS keys, database credentials, dan API tokens. Bot pencari secret di GitHub berjalan 24/7, menunggu developer seperti kamu push credential ke repository publik. Dalam hitungan menit setelah push, bot-bot itu sudah mengekstrak kredensial dan mulai mengakses server kamu, seringkali tanpa sepengetahuanmu.
Cara melakukannya:
- Simpan semua credential di
.envfile (jangan di-commit ke Git!) - Gunakan
.env.examplesebagai template tanpa nilai asli - Pastikan
.envmasuk ke.gitignore - Gunakan secret manager seperti AWS Secrets Manager atau HashiCorp Vault untuk production
- Install git-secrets atau .envscan sebagai pre-commit hook untuk mendeteksi credential sebelum terlanjur di-commit
Waktu yang dibutuhkan: 15 menit untuk audit dan setup.
Langkah 7: Security Headers dan Logging Minimal
Dua hal terakhir yang sering dilupakan: memberi tahu browser cara berperilaku (security headers) dan mencatat apa yang terjadi di aplikasi (logging).
Security Headers yang wajib:
- Content-Security-Policy (CSP) — mencegah XSS dengan membatasi sumber daya yang bisa dimuat halaman
- X-Frame-Options: DENY — mencegah clickjacking dengan melarang halaman dimuat di iframe
- Strict-Transport-Security — memaksa browser selalu menggunakan HTTPS
- X-Content-Type-Options: nosniff — mencegah MIME type sniffing
Gunakan securityheaders.com untuk mengecek skor header aplikasi kamu secara gratis.
Logging dasar: Catat aktivitas mencurigakan: percobaan login gagal berulang, akses ke endpoint yang tidak seharusnya, perubahan data sensitif. Tools seperti Fail2ban bisa membaca log dan secara otomatis memblokir IP yang mencurigakan.
Waktu yang dibutuhkan: 20 menit untuk setup headers + 15 menit untuk logging dasar.
Checklist 7 Langkah dalam Satu Malam
Total waktu untuk semua 7 langkah: 2 jam 5 menit untuk setup pertama kali. Setelah itu, maintenance hanya 5-10 menit per minggu. Bandingkan dengan: 6 bulan kerja keras yang hilang dalam semalam karena database bocor.
| Langkah | Apa yang Dilakukan | Waktu | Tools Gratis |
|---|---|---|---|
| 1. HTTPS | Aktifkan SSL/TLS | 15 menit | Let’s Encrypt, Cloudflare |
| 2. Input Validation | Parameterized queries + server-side validation | 30 menit | Built-in framework |
| 3. Password Hashing | bcrypt/Argon2 | 10 menit | Built-in framework |
| 4. Rate Limiting | Batasi request per IP | 20 menit | express-rate-limit, throttle, django-ratelimit |
| 5. Dependency Scan | Audit library usang | 15 menit | npm audit, pip-audit, Dependabot |
| 6. Environment Vars | Pisahkan credential dari kode | 15 menit | .env, git-secrets |
| 7. Security Headers | CSP, HSTS, X-Frame-Options | 20 menit | securityheaders.com |
Total: 2 jam 5 menit.
Kesimpulan: Keamanan Bukan Fitur Tambahan
Kembali ke kisah Aryo di awal artikel. 12.000 data pengguna bocor. 47 orang kehilangan data pribadi mereka. 6 bulan kerja keras sirna. Jika Aryo menghabiskan 2 jam untuk 7 langkah ini sebelum meluncurkan aplikasinya, ceritanya mungkin berbeda.
Dia mungkin masih menerima feedback dari 47 penggunanya. Dia mungkin masih bisa tidur nyenyak di malam hari. Aplikasinya mungkin masih hidup — dan terus berkembang.
Keamanan bukan fitur tambahan yang bisa dikerjakan “nanti.” Keamanan adalah fondasi yang harus ada SEBELUM aplikasi kamu melihat cahaya dunia. 2 jam sekarang bisa menyelamatkan kamu dari kerugian yang tidak bisa dihitung dengan uang.
Jangan tunda. Ambil checklist di atas, kerjakan satu per satu malam ini. Aplikasi kamu — dan data 47 pengguna pertamamu — akan berterima kasih.
Artikel ini adalah bagian dari seri “7 Langkah Sebelum Launch” untuk solo developer dan startup tahap awal yang ingin meluncurkan aplikasi dengan aman dan percaya diri.