Validasi data masukan dalam aplikasi seluler — dasar-dasar, metode pemeriksaan, dan implementasi

Apa itu validasi data masukan?

Validasi data masukan adalah pemeriksaan bahwa data yang masuk ke aplikasi dari pengguna, layanan eksternal, atau komponen lain sesuai dengan kriteria yang diharapkan. Kriteria ini mencakup tipe data (string, angka, tanggal), format (email, URL, telepon), rentang nilai (usia dari 18 hingga 120), panjang (kata sandi dari 8 hingga 128 karakter), dan karakter yang diizinkan (hanya huruf Latin, angka, tanda hubung). Tanpa validasi, aplikasi dapat memproses data yang menyebabkan kesalahan eksekusi, kerusakan data, atau kerentanan keamanan.

Mengapa validasi adalah elemen keamanan yang kritis?

Tidak adanya validasi data masukan adalah akar penyebab kerentanan seperti SQL Injection, XSS, Command Injection, Path Traversal, dan Buffer Overflow. Menurut MITRE CWE (2025), CWE-20 (Improper Input Validation) menempati posisi kedua dalam peringkat kesalahan perangkat lunak paling berbahaya. Validasi adalah garis pertahanan pertama dalam model keamanan Defense in Depth: validasi memutus data yang salah sebelum mencapai komponen sistem lainnya.

Validasi vs Sanitasi

Validasi menolak data yang tidak memenuhi kriteria. Sanitasi (pembersihan) mengubah data dengan menghapus atau meng-escape bagian yang berbahaya. Misalnya, saat memasukkan konten HTML, validasi dapat memeriksa panjang teks, sedangkan sanitasi dapat menghapus tag script melalui pustaka HTML Purifier atau DOMPurify. Sanitasi tidak menggantikan validasi: keduanya bekerja berpasangan. Validasi adalah kebijakan "diizinkan/dilarang", sanitasi adalah "dibersihkan sebelum digunakan".

Jenis validasi data masukan

Validasi diklasifikasikan berdasarkan kedalaman pemeriksaan. Validasi format adalah yang paling sederhana dan tercepat, sedangkan validasi bisnis adalah yang paling kompleks dan bergantung pada konteks. Ketiga tingkat harus diterapkan secara berurutan: pertama format, kemudian semantik, lalu logika bisnis. Melewatkan tingkat mana pun dapat menyebabkan sistem bekerja tidak benar atau menimbulkan kerentanan.

Validasi format

Pemeriksaan tipe data, ukuran, format, dan karakter yang diizinkan. Diimplementasikan melalui ekspresi reguler, tipe bawaan bahasa, dan pustaka validasi. Contoh: pemeriksaan UUID (format 8-4-4-4-12 digit heksadesimal), pemeriksaan nomor telepon (hanya angka, + di awal, 7 hingga 15 karakter), pemeriksaan bilangan bulat (nilai dalam rentang Integer.MIN_VALUE — Integer.MAX_VALUE). Validasi format adalah tingkat minimum yang diperlukan untuk setiap kolom masukan.

Validasi semantik

Pemeriksaan kebenaran logis data dalam konteks domain. Misalnya: tanggal mulai tidak lebih lambat dari tanggal selesai, usia dalam batas wajar untuk sistem, koordinat berada dalam area layanan. Validasi semantik memerlukan pemahaman konteks bisnis dan tidak dapat dilakukan hanya berdasarkan format. Contoh: kolom "jumlah tiket" dapat lolos pemeriksaan format (bilangan bulat, > 0), tetapi secara semantik tidak boleh melebihi jumlah kursi kosong.

Validasi bisnis

Tingkat paling kompleks — pemeriksaan data terhadap kesesuaian dengan aturan bisnis aplikasi. Contoh: pengguna tidak dapat menghapus satu-satunya administrator, jumlah pesanan tidak melebihi batas kredit, produk hanya dapat dipesan jika tersedia. Validasi bisnis sering memerlukan kueri basis data atau layanan eksternal dan dilakukan setelah pemeriksaan format dan semantik. Kesalahan validasi bisnis adalah penyebab paling umum ketidakpuasan pengguna.

Validasi sisi klien dan server

Validasi sisi klien (di browser atau aplikasi seluler) diperlukan untuk kenyamanan pengguna: umpan balik instan tanpa mengirim data ke server. Namun, validasi server adalah satu-satunya yang andal karena kode klien selalu dapat dilewati. Kirim permintaan melalui alat pengembang, Postman, atau proksi (Burp Suite) — dan validasi sisi klien tidak lagi berfungsi. Menurut PortSwigger Research (2025), lebih dari 90% aplikasi web yang diuji mengandalkan validasi sisi klien secara eksklusif untuk setidaknya satu kolom.

Aturan: klien — untuk UX, server — untuk keamanan

Validasi sisi klien dapat menonaktifkan tombol kirim, menyorot kesalahan, dan menampilkan petunjuk. Validasi server adalah pemeriksaan wajib setiap parameter, meskipun klien telah memeriksanya. Menduplikasi validasi di kedua tingkat adalah praktik standar. Server harus memeriksa data seolah-olah klien tidak ada. Ini menjamin perlindungan dari permintaan yang dimodifikasi, serangan otomatis, dan klien berbahaya.

Implementasi validasi sisi klien

Di web — atribut HTML5 (required, pattern, min/max, type="email") dan JavaScript. Dalam aplikasi seluler — validator bawaan untuk kolom teks (InputFilter di Android, textField(:shouldChangeCharactersIn:) di iOS). React Hook Form dan Formik untuk React, Vuelidate untuk Vue, Angular Reactive Forms — pustaka populer untuk validasi sisi klien. Semuanya mendukung aturan khusus dan validasi asinkron (pemeriksaan keunikan login di server).

// Contoh validasi server di Express dengan Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — data yang sudah diperiksa dan aman
    const user = await User.create(value);
    res.status(201).json(user);
});

Validasi dalam aplikasi seluler

Aplikasi seluler memiliki persyaratan khusus untuk validasi data. Layar lebih kecil — kesalahan harus ringkas, papan ketik kontekstual (numerik untuk memasukkan angka), dan pemeriksaan harus asinkron agar tidak memblokir UI. Platform bawaan menyediakan mekanisme validasi terintegrasi yang harus digunakan secara default. Material Design Guidelines untuk Android dan Human Interface Guidelines untuk iOS berisi rekomendasi terperinci tentang menampilkan kesalahan validasi.

Validasi di Android (Jetpack Compose)

Jetpack Compose menawarkan pendekatan deklaratif untuk validasi melalui manajemen status. Setiap kolom masukan terikat pada status (MutableState), dan kesalahan dihitung berdasarkan nilai saat ini. Pustaka Compose Validator menyederhanakan pembuatan aturan: required, email, min/max length, pattern. Validasi dipicu saat teks berubah (onValueChange) atau saat mencoba mengirim formulir. Disarankan untuk menampilkan kesalahan hanya setelah pengiriman pertama atau setelah pengguna selesai memasukkan (debounce 300-500ms).

Validasi di iOS (SwiftUI)

SwiftUI tidak memiliki mekanisme validasi formulir bawaan, tetapi memungkinkan implementasinya dengan mudah melalui Combine dan property wrappers. Gunakan @State untuk nilai kolom dan properti terhitung untuk kesalahan. Framework ValidatedPropertyKit menyediakan dekorator siap pakai: @Validated().email(), @Validated().range(18...120). Rekomendasi iOS — gunakan tipe papan ketik (UIKeyboardType.emailAddress, .numberPad) dan auto-capitalization untuk mengurangi jumlah kesalahan pada tingkat input.

Validasi di Flutter

Flutter menyediakan kelas Form dan TextFormField dengan validasi bawaan melalui callback validator. Setiap kolom mengembalikan kesalahan sebagai string atau null jika data benar. FormState.validate() menjalankan pemeriksaan semua kolom formulir. Paket reactive_forms untuk kasus kompleks: validator khusus, pemeriksaan asinkron, aturan dinamis. Flutter Web dan versi seluler menggunakan API yang sama, yang menyederhanakan pemeliharaan.

// Contoh validasi formulir di Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

Teknik dan alat validasi

Framework modern menyediakan validator bawaan yang mencakup 80% kebutuhan. Sisanya 20% memerlukan aturan khusus, ekspresi reguler, atau komposisi dari yang sudah ada. Prinsip utama — validasi harus deklaratif sehingga mudah dibaca, diuji, dan dipelihara. Hindari logika validasi yang tersebar di seluruh controller dan layar — pindahkan ke kelas atau skema terpisah.

Pendekatan White-list vs Black-list

White-list (daftar putih) — Anda menentukan data apa yang diizinkan, semua lainnya ditolak. Black-list — Anda menentukan data apa yang dilarang, semua lainnya diizinkan. White-list selalu lebih andal: Anda tahu persis data apa yang akan lolos. Black-list mengharuskan mengantisipasi semua kemungkinan serangan, yang mustahil. Contoh: saat memeriksa usia, gunakan white-list (hanya angka 18 hingga 120), bukan black-list (melarang "0", "-1", "999999").

Ekspresi reguler — kekuatan dan bahaya

Ekspresi reguler adalah alat yang efektif untuk validasi format, tetapi dapat menjadi sumber serangan ReDoS (Regular Expression Denial of Service). Beberapa pola (misalnya, (a+)+b) menyebabkan backtracking katastropik pada string panjang, membebani CPU server sepenuhnya. Gunakan pustaka regex yang teruji dan batasi panjang string sebelum menerapkan ekspresi reguler. Untuk kasus kompleks (email, URL), gunakan parser bawaan bahasa, bukan ekspresi reguler buatan sendiri.

Kesalahan umum dalam validasi

Bahkan pengembang berpengalaman pun membuat kesalahan saat mengimplementasikan validasi. Yang paling umum: validasi hanya di sisi klien, aturan terlalu ketat (kata sandi "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), pesan kesalahan yang tidak informatif ("Error: invalid input"), dan mengabaikan kasus tepi (spasi di awal/akhir, karakter Unicode, string kosong). Setiap kesalahan ini memperburuk UX dan dapat menurunkan konversi formulir.

• Hanya validasi sisi klien — kesalahan paling berbahaya: permintaan apa pun dapat dipalsukan melalui Postman atau cURL
• Aturan terlalu ketat — menjauhkan pengguna: OWASP merekomendasikan persyaratan minimum saat pendaftaran
• Mengabaikan Unicode — pemeriksaan panjang string dalam byte (bukan karakter) merusak bahasa Indonesia, Mandarin, emoji
• Kesalahan tidak informatif — "Invalid format" alih-alih "Email must contain @ symbol after local part"
• Memeriksa kolom kosong — if (value) tidak membedakan string kosong dari nol, false, atau "0"

Praktik terbaik — sistem validasi terpusat yang tercakup oleh unit test. Setiap aturan harus diuji secara terpisah: nilai batas, data yang benar, serangan umum (upaya SQLi, XSS-payloads, string yang sangat panjang). Uji regresi untuk validasi mencegah pelemahan aturan secara tidak sengaja selama refactoring. Gunakan property-based testing (QuickCheck, fast-check) untuk menghasilkan data acak dan memastikan validasi tidak gagal dengan pengecualian.