Form otentikasi yang ditata dengan ds.css bisa tampil halus, tetapi lapisan keamanan ekstra harus tetap dipasang. Pada artikel ini Anda akan langsung melihat cara menambahkan validasi klien, sanitasi, re-validasi di server, pengelolaan sesi/refresh token, dan rate limiting agar flow tetap kuat tanpa mengorbankan pengalaman pengguna.

Kita akan mencontohkan struktur form dengan ds.css, middleware Express yang melindungi endpoint otentikasi, serta strategi pengujian agar UI yang meniru DS/DS Lite tidak melepas kontrol keamanan.

Prinsip Validasi dan Sanitasi di Form ds.css

ds.css menyediakan komponen form yang bersih; Anda bisa memanfaatkan markup sederhana lalu menambahkan logika validasi sebelum data dikirimkan. Fokus utama di sisi klien adalah memastikan data sesuai format yang diharapkan (email, kata sandi panjang minimum) dan tidak mengandung payload berbahaya.

Contoh Form ds.css dengan Validasi Klien

<form id="loginForm" class="ds-form" novalidate>
  <label class="ds-label" for="email">Email</label>
  <input class="ds-input" id="email" name="email" type="email" required />

  <label class="ds-label" for="password">Kata Sandi</label>
  <input class="ds-input" id="password" name="password" type="password" minlength="8" required />

  <button class="ds-btn ds-btn-primary" type="submit">Masuk</button>
</form>

<script>
const form = document.getElementById('loginForm');
form.addEventListener('submit', (event) => {
  event.preventDefault();
  const email = form.email.value.trim();
  const password = form.password.value;
  const emailPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!emailPattern.test(email)) {
    alert('Email tidak valid.');
    return;
  }
  if (password.length < 8) {
    alert('Kata sandi minimal 8 karakter.');
    return;
  }
  form.submit();
});
</script>

Validasi di atas menangkap kesalahan format paling umum. Sanitasi tambahan bisa dilakukan dengan memanggil fungsi untuk menghapus karakter yang bukan ASCII atau mengecek panjang maksimum sebelum mengirim.

Re-validasi dan Sanitasi di Server

Validasi klien berguna, tapi jangan percaya output pengguna. Server wajib mengecek ulang input untuk mencegah SQL injection, log injection, atau credential stuffing. Terapkan validasi tipe data, panjang, dan pola secara eksplisit.

app.post('/api/auth/login', express.json(), async (req, res) => {
  const { email, password } = req.body;
  if (typeof email !== 'string' || typeof password !== 'string') {
    return res.status(400).json({ error: 'Payload tidak valid.' });
  }
  const trimmedEmail = email.trim().toLowerCase();
  if (!trimmedEmail || trimmedEmail.length >= 254 || password.length < 8) {
    return res.status(400).json({ error: 'Data tidak memenuhi syarat.' });
  }
  const user = await findUserByEmail(trimmedEmail);
  if (!user || !(await bcrypt.compare(password, user.passwordHash))) {
    return res.status(401).json({ error: 'Email atau kata sandi salah.' });
  }
  // lanjutkan dengan sesi / token
});

Memangkas email dan memvalidasi panjang membantu menghindari input terlalu panjang atau spasi berlebihan yang bisa memecahkan log. Hindari mengembalikan detail tentang pengguna yang tidak valid untuk mencegah enumerasi.

Pengelolaan Session, Refresh Token, dan Secret

Representasi session bisa berupa cookie HttpOnly yang berisi identifier, atau access token JWT dengan masa hidup singkat. Di sisi klien, gunakan HttpOnly cookie agar skrip tidak bisa mengakses token. Untuk menjaga session, kombinasikan:

  • Access token (misalnya JWT dengan scope terbatas) dan refresh token yang disimpan di server (database/Redis).
  • Penegasan revocation: simpan versi token di basis data dan batasi jumlah refresh token per akun.
  • Pengaturan secret dengan environment variable dan rotasi rutin, serta catat rotasi untuk debugging.

Pada route refresh, validasi user agent, IP jika dibutuhkan, dan periksa apakah refresh token masih aktif sebelum mengeluarkan token baru.

Rate Limit, Middleware, dan Header Keamanan

Endpoint auth menjadi sasaran brute force, sehingga tambahkan rate limiting dan header keamanan:

import rateLimit from 'express-rate-limit';
import helmet from 'helmet';

app.use(helmet({
  contentSecurityPolicy: false
}));

const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: 'Terlalu banyak percobaan login. Coba beberapa saat lagi.' }
});

app.use('/api/auth/', authLimiter);

Gunakan header seperti Strict-Transport-Security, Referrer-Policy, dan Content-Security-Policy dari helmet untuk mengurangi serangan injeksi dan clickjacking. Untuk mencegah abuse tambahan, pertimbangkan kombinasi CAPTCHA dan throttle per IP/username.

Strategi Testing dan Monitoring Auth Flow

Jaga hardening dengan pengujian berlapis:

  • Unit test validator server untuk berbagai kasus input invalid.
  • Integration test form ds.css dengan alat seperti Playwright untuk memastikan pesan error muncul.
  • Test rate limit dengan membuat beberapa request build-in dan pastikan status 429.
  • Penetration test sederhana: coba brute force terbatas untuk memeriksa loging dan throttle.

Tambahkan monitoring pada endpoint auth (latency, jumlah 401/429) dan tingkatkan alert ketika aktivitas mencurigakan terjadi. Dengan cara ini, UI yang meniru DS/DS Lite tetap mengikuti standar keamanan yang sama.

Dengan kombinasi validasi klien, sanitasi, middleware keamanan, dan pengujian, auth flow berbasiskan ds.css dapat tampil ringkas sekaligus tangguh terhadap abuse.