Sejak 26 Oktober 2021, pembelian tiket kereta api jarak jauh wajib memakai NIK, baik untuk penumpang dewasa maupun anak-anak. KAI menyebut aturan ini sebagai dukungan terhadap Perpres No. 83 Tahun 2021 tentang pencantuman dan pemanfaatan NIK dalam pelayanan publik. Sejak itu, jutaan orang mengisi NIK di aplikasi tiket tanpa banyak berpikir, karena memang tidak ada pilihan lain.
Pertanyaannya bergeser ke sisi lain. Setelah NIK tersimpan, bagaimana aplikasi memperlakukannya? Buka halaman akun di aplikasi tiket kereta, dan NIK kita tampil lagi di sana. Kita yang membuka tentu tidak keberatan, karena itu nomor kita sendiri. Tetapi layar itu bisa terlihat orang di sebelah, tertangkap tangkapan layar yang dikirim ke grup, atau terekam saat seseorang meminjam ponsel kita sebentar.
Di sinilah letak persoalannya. Kewajiban memberikan NIK tidak otomatis berarti NIK boleh dipajang utuh di setiap layar. Dua hal itu diatur oleh logika yang berbeda. Tulisan ini membahas aturan menampilkan NIK di web dan aplikasi, dan apa yang sebaiknya dilakukan developer supaya sistemnya aman dari sisi teknis maupun hukum.
Mengapa Menampilkan NIK Tidak Boleh Asal
NIK terdiri dari 16 digit, dan setiap bagiannya membawa informasi. Enam digit pertama menunjukkan wilayah penerbitan seperti provinsi, kabupaten atau kota, dan kecamatan. Enam digit berikutnya adalah tanggal lahir, dengan tanggal perempuan ditambah 40. Empat digit terakhir adalah nomor urut.
Jadi, siapa pun yang memegang NIK lengkap sudah tahu asal daerah dan tanggal lahir pemiliknya, bahkan sebelum tahu namanya. Nomor yang sama dipakai untuk pajak, BPJS, layanan keuangan, dan banyak verifikasi lain. Kalau bocor, nomor ini bisa dipakai untuk menyamar sebagai pemiliknya.
Karena itu, keputusan menampilkan NIK di layar bukan soal desain antarmuka. Ini keputusan keamanan.
Dasar Hukum Menampilkan NIK
Ada dua undang-undang yang jadi pegangan.
Yang pertama UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi, atau UU PDP. Masa transisinya dua tahun, jadi seluruh kewajibannya berlaku penuh sejak 17 Oktober 2024. NIK memang tidak disebut satu per satu dalam daftar data umum di Pasal 4. Tetapi karena bisa dipakai untuk mengenali seseorang, dalam praktik ia diperlakukan sebagai data pribadi.
Yang kedua UU Administrasi Kependudukan (UU No. 24 Tahun 2013). Undang-undang ini menegaskan bahwa data kependudukan wajib dilindungi, dan orang yang menyebarluaskannya tanpa hak bisa dipidana lewat Pasal 95A.
Kondisi terbarunya perlu dicatat. UU PDP sudah punya aturan pelaksana berupa PP No. 33 Tahun 2026, tetapi lembaga pengawasnya belum terbentuk, dan para pengamat menilai penerapannya belum efektif. Bukan berarti kewajibannya boleh diabaikan. Ketentuan UU PDP tetap mengikat, dan ketentuan pidananya tetap bisa ditegakkan aparat penegak hukum. Menunggu lembaganya jadi baru berbenah adalah taruhan yang buruk.
Tiga Pertanyaan Sebelum Menampilkan NIK
Tidak ada pasal yang melarang menampilkan NIK secara mutlak. Yang ada adalah syarat. Dari prinsip pemrosesan di Pasal 16 dan dasar pemrosesan di Pasal 20, saya meringkasnya menjadi tiga pertanyaan.
Untuk apa? Data pribadi hanya boleh diproses secara terbatas dan spesifik, sesuai tujuan yang diberitahukan kepada pemiliknya. Atas dasar apa? Bisa persetujuan yang eksplisit, kewajiban hukum, pelaksanaan perjanjian, atau dasar lain yang disebut undang-undang. Perlu utuh atau tidak? Kalau tampilan sebagian sudah cukup untuk tujuan itu, sulit membenarkan menampilkan seluruh digit.
Ada kasus yang jelas. Bukti potong dan faktur pajak harus memuat NIK, dan Ditjen Pajak menyatakan hal itu tidak melanggar UU PDP karena ada pengecualian untuk kepentingan umum dalam penyelenggaraan negara. Dasar hukumnya kuat. Halaman profil biasa atau tabel riwayat transaksi tidak punya dasar sekuat itu.
Masking: Cara Paling Murah untuk Menampilkan NIK dengan Aman
Satu hal perlu diluruskan lebih dulu. Sejauh yang saya temukan, belum ada aturan yang menetapkan format masking NIK secara baku. Masking adalah praktik pengamanan yang diturunkan dari prinsip pembatasan data dan kewajiban menjaga keamanan. Beberapa pemerintah daerah bahkan sudah mengeluarkan edaran yang meminta data seperti NIK, nama, dan alamat disensor kalau harus disampaikan lewat situs atau aplikasi.
Untuk kebanyakan kebutuhan, menyisakan empat digit terakhir sudah cukup bagi pengguna untuk mengenali nomornya sendiri:
function maskNik(nik) {
const digits = String(nik).replace(/\D/g, "");
if (digits.length !== 16) return "";
return "************" + digits.slice(-4);
}
// 3404123456789012 -> ************9012Pola ini menyembunyikan kode wilayah dan tanggal lahir, yaitu bagian yang paling banyak membocorkan informasi.
Kesalahan yang paling sering saya lihat: masking dikerjakan di front-end, sementara API tetap mengirim NIK utuh. Buka tab Network di browser, dan semuanya terbaca. Masking harus dilakukan di server. Klien cukup menerima apa yang memang akan ditampilkan, tidak lebih.
Kalau suatu peran memang perlu melihat NIK utuh, misalnya petugas verifikasi, sediakan tombol “tampilkan” yang hanya aktif untuk peran itu, dan catat setiap pemakaiannya di audit log.
Enkripsi: Melindungi NIK yang Tersimpan
Masking hanya mengatur apa yang terlihat. Di database, NIK tetap tersimpan apa adanya kalau tidak dienkripsi. Keduanya bekerja berpasangan: masking untuk tampilan, enkripsi untuk data yang tersimpan.
UU PDP mewajibkan pengendali data menjaga keamanan data, tetapi tidak menyebut algoritma tertentu. Pilihan teknisnya ada di tangan tim Anda. Yang umum dipakai adalah AES-256-GCM, karena selain menyembunyikan isi, mode GCM juga bisa mendeteksi kalau data diubah pihak lain. Contoh di Node.js:
import crypto from "node:crypto";
// key: Buffer 32 byte, diambil dari secret manager / KMS
export function encryptNik(nik, key) {
const iv = crypto.randomBytes(12); // harus acak, jangan dipakai ulang
const cipher = crypto.createCipheriv("aes-256-gcm", key, iv);
const enc = Buffer.concat([cipher.update(nik, "utf8"), cipher.final()]);
const tag = cipher.getAuthTag();
return Buffer.concat([iv, tag, enc]).toString("base64");
}
export function decryptNik(payload, key) {
const raw = Buffer.from(payload, "base64");
const iv = raw.subarray(0, 12);
const tag = raw.subarray(12, 28);
const enc = raw.subarray(28);
const decipher = crypto.createDecipheriv("aes-256-gcm", key, iv);
decipher.setAuthTag(tag);
return Buffer.concat([decipher.update(enc), decipher.final()]).toString("utf8");
}Kodenya pendek. Yang membuat enkripsi ini berguna atau sia-sia adalah hal-hal di sekitarnya.
Kunci. Kalau kunci tersimpan di repositori, di file .env yang ikut ter-commit, atau di tabel yang sama dengan NIK, enkripsinya hanya formalitas. Simpan di secret manager atau layanan KMS milik penyedia cloud Anda. Lebih baik lagi dengan envelope encryption: data dienkripsi dengan kunci data, dan kunci data itu dienkripsi lagi dengan kunci utama di KMS. Rotasi kunci jadi jauh lebih mudah.
Hash bukan pengganti enkripsi. Ruang kemungkinan NIK relatif kecil dan polanya bisa ditebak, jadi hash SHA-256 polos bisa dibongkar dengan brute force. Hash juga tidak bisa dikembalikan ke bentuk asal, padahal suatu saat NIK mungkin perlu ditampilkan.
Pencarian. Data terenkripsi tidak bisa dicari dengan WHERE nik = ..., karena IV acak membuat hasil enkripsi selalu berbeda. Solusinya blind index, yaitu kolom tambahan berisi HMAC dari NIK:
export function nikBlindIndex(nik, hmacKey) {
return crypto.createHmac("sha256", hmacKey).update(nik).digest("hex");
}Saat mencari, hitung HMAC dari NIK yang dimasukkan, lalu cocokkan dengan kolom itu. Pakai kunci HMAC yang berbeda dari kunci enkripsi.
Data yang bergerak. Pakai TLS di semua jalur, termasuk antar layanan internal, dan pastikan backup ikut terenkripsi. Batasi pula siapa yang boleh mendekripsi. Idealnya hanya layanan yang memang perlu, dan setiap dekripsi tercatat.
Alur yang sehat jadi begini: NIK masuk lewat HTTPS, dienkripsi sebelum disimpan, didekripsi hanya saat benar-benar dibutuhkan, lalu di-mask di server sebelum sampai ke tampilan.
Tempat-Tempat yang Sering Terlupa Saat Menampilkan NIK
Menurut pengamatan saya, kebocoran jarang terjadi di halaman utama. Biasanya di tempat yang tidak pernah diperiksa.
NIK di URL atau query string, seperti /profil?nik=..., terekam di riwayat browser, log server, dan header referrer. Pakai ID internal yang acak. NIK yang ikut tertulis di log aplikasi atau layanan pelacak error juga berbahaya, karena log dibaca banyak orang dan disimpan lama. Saring field NIK sebelum sampai ke log.
Notifikasi push, subjek email, dan SMS bisa terbaca dari layar kunci. Ekspor CSV dari panel admin sering melewati masking yang sudah dipasang di antarmuka. Data produksi yang disalin ke lingkungan staging perlu diganti dengan data fiktif.
Terakhir, endpoint yang menerima ID dari klien tanpa memeriksa kepemilikannya. Celah ini disebut IDOR, dan memungkinkan pengguna melihat NIK orang lain hanya dengan mengganti satu angka di permintaan.
Kalau NIK Sudah Terlanjur Bocor
UU PDP membebankan kewajiban pada pengendali data, yaitu pihak yang menentukan tujuan pemrosesan. Developer sering bukan pengendalinya, tetapi sistem yang dibangun menentukan apakah kewajiban itu bisa dipenuhi.
Pengendali wajib menjaga keamanan data dan mencegah akses tanpa hak (Pasal 35 dan 39). Kalau terjadi kegagalan pelindungan data, pemberitahuan tertulis kepada pemilik data dan lembaga berwenang harus disampaikan paling lambat 3 × 24 jam (Pasal 46). Tenggat sesingkat itu hanya bisa dipenuhi kalau log akses rapi, sehingga tim bisa menjawab siapa mengakses apa dan kapan.
Sanksinya tidak ringan. Denda administratif bisa mencapai 2 persen dari pendapatan tahunan (Pasal 57). Secara pidana, tindakan seperti mengungkapkan atau menggunakan data pribadi milik orang lain diancam penjara dan denda miliaran rupiah (Pasal 65 sampai 67). Organisasi yang memproses data dalam skala besar atau untuk pelayanan publik juga wajib menunjuk pejabat pelindungan data pribadi (Pasal 53).
Menampilkan NIK dengan Benar Dimulai dari Desain
Intinya sederhana. Tampilkan NIK hanya kalau ada tujuan yang sah, tampilkan sesedikit mungkin, dan jaga jalurnya dari database sampai layar. Tim yang memikirkan ini sejak tahap desain biasanya jauh lebih tenang saat audit dibanding tim yang menambalnya setelah ada insiden.
Satu catatan terakhir: tulisan ini bersifat informatif, bukan nasihat hukum. Contoh kode adalah praktik umum keamanan, bukan kewajiban yang tertulis di UU PDP atau PP 33/2026, dan perlu diuji di lingkungan Anda sendiri. Untuk sistem yang memproses NIK dalam skala besar, konsultasikan dengan penasihat hukum atau pakar pelindungan data pribadi.
