Secure Coding Principles

Aplikasi yang lulus semua test fungsional belum tentu aman, karena test biasa memeriksa apa yang terjadi ketika pengguna bersikap wajar, bukan ketika seseorang sengaja mengirim input yang merusak. Keamanan menuntut cara berpikir terbalik: setiap pintu masuk data dianggap akan diserang. Seluruh chapter pada section ini membahas ancaman spesifik beserta pertahanannya, dan semuanya berpijak pada segelintir prinsip dasar yang akan kita kuasai lebih dulu di sini.

Prinsip-Prinsip yang Menjaga Kode Kita #

Enam prinsip berikut muncul berulang kali di seluruh materi keamanan. Organisasi OWASP menyusun risiko keamanan aplikasi web terpopuler dalam daftar OWASP Top 10 — dan hampir setiap itemnya bisa dicegah dengan kombinasi prinsip ini.

Prinsip	Makna singkat	Contoh penerapan
Least privilege	Beri hak akses seminimal yang dibutuhkan	Akun database aplikasi hanya boleh `SELECT` dan `INSERT`, tanpa hak `DROP TABLE`
Defense in depth	Susun beberapa lapis pertahanan	Validasi input, parameterized query, dan pembatasan hak akses database bekerja berlapis
Fail securely	Saat terjadi error, tolak aksesnya	Token konfigurasi gagal dibaca berarti permintaan ditolak, bukan diizinkan
Never trust input	Data dari luar dianggap berbahaya sampai terbukti bersih	Komentar pengguna divalidasi sebelum ditampilkan di halaman HTML
Secure defaults	Konfigurasi bawaan harus aman tanpa pengaturan tambahan	Mode debug mati secara otomatis di server produksi
Security vs convenience	Kenyamanan tidak boleh dibayar dengan celah keamanan	Fitur “ingat saya” memperpanjang umur sesi dan memperluas permukaan serangan

Prinsip-prinsip ini bukan teori kosong. Dokumen rujukan seperti OWASP Application Security Verification Standard (ASVS) dan OWASP Cheat Sheets menerjemahkannya menjadi daftar periksa konkret yang dipakai industri saat mengaudit aplikasi.

Fail Securely #

Cabang error adalah jalur kode yang paling jarang diuji, dan justru di sanalah penyerang suka berdiam. Ketika exception menghentikan alur normal, kode di blok except yang menentukan nasib sebuah akses: diizinkan atau ditolak. Perhatikan dua versi pemeriksaan izin berikut — versi pertama sengaja kita tandai sebagai berbahaya:

python
PERAN_PENGGUNA = {"budi": "admin", "siti": "viewer"}


def cek_izin_fail_open(username, peran_dibutuhkan):
    # RISIKO: error apa pun jatuh ke cabang "diizinkan"
    try:
        return PERAN_PENGGUNA[username] == peran_dibutuhkan
    except KeyError:
        return True  # pengguna tak dikenal malah dianggap berhak


def cek_izin_fail_closed(username, peran_dibutuhkan):
    try:
        return PERAN_PENGGUNA[username] == peran_dibutuhkan
    except KeyError:
        return False  # pengguna tak dikenal ditolak


print("fail_open  ('hacker', 'admin') :", cek_izin_fail_open("hacker", "admin"))
print("fail_closed('hacker', 'admin') :", cek_izin_fail_closed("hacker", "admin"))

Output yang Dihasilkan:

text

fail_open  ('hacker', 'admin') : True
fail_closed('hacker', 'admin') : False

Mari kita bedah dua fungsi di atas:

Baris 4-9 (cek_izin_fail_open): dictionary PERAN_PENGGUNA tidak memuat kunci "hacker", sehingga ekspresi PERAN_PENGGUNA[username] memunculkan KeyError. Blok except menelan error tersebut dan mengembalikan True — pengguna yang tidak dikenal justru dianggap berhak mendapat peran admin.
Baris 12-17 (cek_izin_fail_closed): mekanisme error identik, tetapi blok except mengembalikan False. Kegagalan membaca data berarti akses ditolak, bukan diizinkan.
Baris 19-20 (print(...)): kedua fungsi diuji dengan pengguna tak dikenal; hasilnya berlawanan. Versi fail-open membuka pintu bagi penyerang tepat pada momen sistem sedang bermasalah.

Aturan praktisnya sederhana: ketika sebuah pemeriksaan keamanan tidak bisa dijalankan, satu-satunya jawaban yang aman adalah menolak. Pola yang sama berlaku di banyak tempat — middleware autentikasi yang gagal membaca token harus menolak request, dan operasi database yang gagal di tengah transaksi harus di-rollback, bukan dibiarkan setengah jadi.

Keamanan vs Kenyamanan #

Hampir setiap keputusan keamanan adalah tarik-menarik dengan kenyamanan. Pesan error yang menampilkan struktur SQL mempercepat debugging, tetapi membocorkan skema database kepada penyerang — kita akan melihat buktinya pada Chapter SQL Injection. Sesi login yang berbulan-bulan lamanya menghindarkan pengguna dari mengetik password, tetapi juga memberi penyerang waktu luas untuk memalsukan sesi.

Kebiasaan yang sehat adalah menyadari tarik-menarik tersebut secara eksplisit: nyatakan apa yang dikorbankan setiap kali kenyamanan ditambahkan. Dengan enam prinsip di atas, kita siap masuk ke pertahanan lapis pertama setiap aplikasi — memvalidasi dan membersihkan input pada Chapter Validasi dan Sanitasi Input.