Pada aplikasi ear training berbasis web yang dipakai publik seperti ToneDear, masalah keamanan backend jarang berhenti di login dan logout. Endpoint yang tampak sederhana—register, reset password, custom quiz, leaderboard, sampai submit skor—sering menjadi target credential stuffing, brute force, bot signup, session fixation, replay, dan spam submission.

Hardening Ear Training App: Auth, Session, dan Anti-Abuse berarti membangun kontrol yang cukup ketat untuk aplikasi gratis dan ramai dipakai, tanpa membuat UX hancur. Fokus yang paling berguna biasanya bukan sistem auth yang rumit, tetapi kombinasi desain session yang benar, validasi input yang ketat, proteksi endpoint publik, rate limiting yang masuk akal, dan observability yang memadai untuk mendeteksi abuse.

Model ancaman untuk aplikasi ear training publik

Sebelum memilih middleware atau menambah CAPTCHA, pahami dulu pola serangan yang realistis untuk produk seperti ini.

1. Credential stuffing dan brute force

Jika aplikasi punya akun gratis, maka login endpoint akan diuji memakai kombinasi email/password hasil kebocoran dari layanan lain. Ini bukan serangan canggih, tetapi sangat umum. Brute force klasik juga tetap terjadi, terutama pada akun dengan email yang mudah ditebak.

2. Bot signup dan abuse akun gratis

Karena produk gratis, penyerang bisa membuat banyak akun untuk spam leaderboard, farming fitur tertentu, atau sekadar menguji otomasi. Jika register terlalu murah dan tidak dibatasi, database pengguna akan cepat penuh data sampah.

3. Session fixation, session hijacking, dan replay

Pada aplikasi berbasis cookie session, risiko umum meliputi:

  • Session fixation: attacker memaksa korban memakai session ID yang sudah diketahui sebelum login.
  • Session hijacking: cookie dicuri lewat XSS, koneksi tidak aman, atau perangkat bersama.
  • Replay: request penting seperti submit skor atau reset token dipakai ulang.

4. Abuse pada custom quiz dan endpoint publik

Fitur latihan yang menerima parameter seperti interval, tempo, jumlah soal, mode suara, atau konfigurasi custom quiz rawan disalahgunakan. Tanpa validasi yang ketat, penyerang bisa:

  • mengirim payload sangat besar,
  • memicu query mahal,
  • memaksa pembuatan data tak masuk akal,
  • menggunakan input tak tervalidasi untuk menabrak logika scoring.

5. Spam score submission dan manipulasi leaderboard

Leaderboard publik hampir selalu menarik abuse. Risiko umumnya:

  • mengirim skor palsu langsung ke endpoint backend,
  • mengulang request submit yang sama berkali-kali,
  • mem-bypass urutan permainan dengan submit hasil tanpa memulai sesi latihan yang sah,
  • membanjiri leaderboard dengan akun bot.

Desain auth sederhana yang cocok untuk akun gratis

Untuk aplikasi ear training publik, auth yang baik tidak harus kompleks. Pilihan yang paling aman dan operasionalnya ringan biasanya adalah session-based auth dengan cookie HttpOnly untuk web biasa.

Kenapa session cookie sering lebih cocok daripada token di browser

Jika frontend dan backend berada pada domain yang sama atau masih dalam kendali yang jelas, cookie session lebih aman dibanding menyimpan token bearer di localStorage. Alasan utamanya:

  • cookie HttpOnly tidak bisa dibaca JavaScript, sehingga mengurangi dampak XSS terhadap pencurian token,
  • browser punya mekanisme native untuk pengiriman cookie, expiry, dan atribut keamanan,
  • lebih mudah digabungkan dengan proteksi CSRF yang standar.

Token bearer tetap valid pada arsitektur tertentu, tetapi untuk aplikasi web publik yang relatif tradisional, session cookie biasanya lebih sederhana dan lebih sulit disalahgunakan dari sisi client storage.

Prinsip desain login/register yang cukup aman

  • Simpan password dengan algoritma hashing modern yang dirancang untuk password, bukan hash umum cepat.
  • Jangan bedakan pesan error login secara terlalu spesifik. Hindari memberitahu apakah email terdaftar atau tidak pada login.
  • Regenerasi session ID setelah login berhasil untuk mencegah session fixation.
  • Invalidasi session aktif saat password diubah atau reset berhasil.
  • Pertimbangkan verifikasi email untuk mengurangi bot signup, tetapi jangan jadikan itu satu-satunya kontrol anti-abuse.

Contoh alur auth minimal

  1. User submit email dan password.
  2. Backend cek rate limit berdasarkan kombinasi IP, email yang dinormalisasi, dan fingerprint risiko sederhana.
  3. Jika lolos, backend verifikasi password hash.
  4. Jika sukses, backend buat session baru dan regenerate session ID.
  5. Set cookie dengan atribut aman.
  6. Catat event login sukses/gagal untuk audit dan deteksi abuse.

Proteksi session cookie yang benar

Session cookie adalah fondasi. Banyak celah justru datang dari konfigurasi cookie yang longgar.

Atribut cookie yang sebaiknya diaktifkan

  • HttpOnly: mencegah akses langsung lewat JavaScript.
  • Secure: cookie hanya dikirim lewat HTTPS.
  • SameSite: membantu mengurangi CSRF. Pilihan umum adalah Lax untuk aplikasi web biasa.
  • Path dan Domain sesempit mungkin: jangan terlalu luas jika tidak perlu berbagi lintas subdomain.

Session fixation: kesalahan yang sering lolos review

Bug klasiknya sederhana: aplikasi membuat session anonim, lalu setelah login tetap memakai session ID yang sama. Kalau attacker lebih dulu mengetahui session ID itu, ia bisa menempel ke sesi korban setelah korban login.

Solusinya adalah rotasi atau regenerasi session ID setiap kali privilege berubah, terutama setelah login, setelah verifikasi MFA jika ada, dan setelah reset password.

Timeout session: keamanan vs kenyamanan

Session terlalu panjang meningkatkan risiko pada perangkat bersama. Session terlalu pendek mengganggu UX, terutama untuk pengguna yang sedang latihan musik cukup lama.

Pendekatan yang masuk akal:

  • gunakan idle timeout untuk sesi login,
  • gunakan absolute expiration agar session tidak hidup terlalu lama,
  • untuk aksi sensitif seperti ganti email atau password, minta re-authentication singkat.

Jangan mencampur kebutuhan UX latihan dengan kebutuhan keamanan akun. User boleh tetap mengakses latihan anonim atau mode ringan tanpa login, tetapi perubahan data akun tetap butuh session yang kuat.

CSRF dan alur middleware yang aman

Jika memakai cookie session, maka proteksi CSRF penting untuk semua request yang mengubah state: register, logout, update profil, custom quiz yang disimpan, submit skor, dan reset password yang difinalisasi dari form.

Kapan CSRF relevan

CSRF relevan ketika browser otomatis mengirim cookie ke backend. Jika endpoint menerima cookie session dan request dapat dipicu dari situs lain, attacker bisa mencoba memanfaatkan browser korban untuk mengirim aksi yang tidak diinginkan.

Pola proteksi CSRF yang umum

  • Set cookie session dengan SameSite=Lax atau lebih ketat jika memungkinkan.
  • Gunakan token CSRF per session atau per form untuk request mutasi.
  • Validasi Origin atau Referer sebagai lapisan tambahan pada endpoint sensitif, jika arsitektur memungkinkan.

Contoh urutan middleware request

Request masuk
  - TLS termination / reverse proxy sanity check
  - Trusted proxy validation
  - Request size limit
  - Basic bot / IP reputation filter
  - Rate limiter
  - Session load
  - CSRF validation (untuk state-changing request)
  - Authentication check
  - Input validation & normalization
  - Authorization / ownership check
  - Business logic
  - Audit log / metrics emit
  - Response

Urutan ini penting. Misalnya, validasi ukuran request dan rate limit sebaiknya terjadi sebelum business logic berat. CSRF dilakukan setelah session tersedia, tetapi sebelum proses mutasi dijalankan.

Validasi input pada latihan dan custom quiz

Pada aplikasi ear training, banyak developer fokus pada validasi akun, tetapi melupakan endpoint latihan karena dianggap “cuma parameter musik”. Padahal input seperti ini justru sering dipakai untuk abuse.

Prinsip validasi yang disarankan

  • Gunakan allowlist, bukan blacklist. Hanya terima nilai yang benar-benar dikenal.
  • Batasi panjang array, rentang angka, dan ukuran payload JSON.
  • Normalisasi input sebelum dipakai untuk cache key, query, atau hashing.
  • Tolak field tambahan yang tidak dikenal pada endpoint sensitif.
  • Jangan percaya skor, durasi, atau status progres dari client.

Contoh input yang harus dibatasi

  • questionCount: harus dalam rentang yang masuk akal.
  • tempo: jangan biarkan angka ekstrem jika memicu beban proses audio atau query tambahan.
  • intervals atau notes: panjang maksimum jelas, hanya nilai musik yang valid.
  • mode: enum eksplisit, bukan string bebas.
  • quizName: panjang dibatasi, karakter dikontrol, di-escape saat ditampilkan.

Contoh skema validasi pseudo-code

validateCustomQuiz(payload):
  assert payload is object
  reject unknown fields

  mode in ["interval", "chord", "scale"]
  questionCount is integer and between 1..50
  tempo is integer and between 40..240
  notes is array and length between 1..12
  every note in allowedNoteSet
  quizName length <= 80

  if mode == "interval":
    intervals is array and every item in allowedIntervalSet

  return normalizedPayload

Kenapa ini efektif? Karena Anda menutup jalur payload aneh sejak awal, mengurangi risiko query tidak efisien, data korup, dan bug logika scoring.

Kesalahan umum

  • Validasi hanya di frontend.
  • Menerima JSON dengan field ekstra lalu mengabaikannya diam-diam.
  • Menyimpan konfigurasi custom quiz mentah tanpa normalisasi.
  • Menggunakan nilai dari client sebagai sumber kebenaran untuk skor akhir.

Secret handling untuk API key dan environment

Aplikasi publik sering memakai layanan email, CAPTCHA, observability, object storage, atau abuse detection. Kunci API untuk layanan-layanan ini adalah target yang sering bocor lewat konfigurasi buruk.

Praktik dasar yang harus ada

  • Simpan secret di environment variable atau secret manager, bukan di source code.
  • Jangan commit file env produksi ke repository.
  • Bedakan secret per environment: local, staging, production.
  • Rotasi secret jika terindikasi bocor.
  • Batasi scope API key sesuai kebutuhan layanan.

Hal yang sering terlewat

  • Secret ikut tercetak di log error atau dump exception.
  • File konfigurasi build frontend secara tidak sengaja mem-publish key server-side ke browser.
  • Container image berisi file env atau credential sementara.
  • Backup database atau snapshot instance menyimpan token reset atau session secara plaintext.

Aturan praktis

Jika sebuah key memberi akses menulis data, mengirim email, menghapus resource, atau membaca data sensitif, anggap itu server secret. Jangan pernah anggap aman hanya karena key tersebut “susah ditebak”.

Rate limiting untuk login, register, dan reset password

Rate limiting bukan sekadar membatasi request per IP. Untuk endpoint auth, kontrol yang efektif biasanya memakai beberapa dimensi sekaligus.

Strategi rate limiting yang lebih realistis

  • Per IP: bagus untuk memblokir serangan kasar, tetapi mudah di-bypass dengan proxy botnet.
  • Per account identifier: misalnya per email yang dinormalisasi, untuk melindungi akun tertentu dari brute force.
  • Per device/session sementara: berguna untuk pola abuse berulang dari client yang sama.
  • Global limiter pada endpoint sensitif: mencegah lonjakan besar merusak sistem.

Endpoint yang wajib dilimit

  • login
  • register
  • forgot password
  • reset password finalization
  • email verification resend
  • score submission
  • leaderboard query jika mahal atau sering dipanggil bot

Contoh kebijakan praktis

Daripada satu limit kaku, gunakan pendekatan bertingkat:

  • percobaan gagal login berulang pada email yang sama memicu cooldown progresif,
  • register dari satu IP atau subnet dalam waktu singkat memicu challenge tambahan,
  • forgot password untuk akun yang sama dibatasi ketat agar tidak dipakai spam email.

Ini lebih ramah UX daripada langsung memblokir semua user di jaringan bersama, namun tetap menahan pola abuse.

Trade-off UX vs keamanan

Rate limit terlalu ketat bisa merugikan pengguna sungguhan, terutama di sekolah, kampus, atau studio musik yang berbagi satu IP. Solusi yang lebih baik adalah step-up protection: mulai dari throttle ringan, lalu naikkan challenge hanya jika sinyal risiko meningkat.

Pencegahan abuse pada endpoint publik dan leaderboard

Bagian ini biasanya paling sering dilupakan karena tampak bukan area sensitif. Padahal justru mudah diserang.

Jangan percaya skor dari client

Client boleh mengirim jawaban, event, atau progres, tetapi backend sebaiknya menjadi pihak yang menentukan apakah sebuah skor valid. Minimalnya, backend harus dapat memverifikasi bahwa:

  • ada sesi permainan yang sah sebelum submit skor,
  • konfigurasi quiz yang dipakai valid dan konsisten,
  • jumlah soal, jawaban, dan durasi masih masuk akal,
  • request submit belum pernah diproses sebelumnya.

Pakai game/quiz attempt yang ditandatangani server

Alih-alih menerima submit skor bebas, gunakan konsep attempt:

  1. User memulai quiz.
  2. Backend membuat attempt_id acak, mengikatnya ke user/session, mode quiz, waktu mulai, dan status aktif.
  3. Client menjawab soal.
  4. Client submit hasil dengan attempt_id.
  5. Backend menghitung atau memverifikasi hasil dari data yang dipercaya, lalu menandai attempt selesai.

Dengan model ini, spam score submission jadi lebih sulit karena submit harus terkait ke sesi permainan yang benar. Anda juga bisa menolak attempt yang sudah selesai untuk mencegah replay.

Idempotency dan anti-replay

Untuk endpoint seperti submit skor atau reset password, pikirkan serangan replay. Solusi praktis:

  • gunakan token satu kali pakai untuk aksi tertentu,
  • simpan status token/attempt sebagai consumed setelah dipakai,
  • gunakan idempotency key jika endpoint rentan retry dari client.

Moderasi leaderboard yang pragmatis

Tidak semua abuse perlu ditangani secara real-time. Untuk leaderboard publik:

  • simpan sinyal risiko per submit,
  • pisahkan leaderboard publik dari tabel raw submissions,
  • beri status pending review atau shadow banned untuk submit yang sangat mencurigakan,
  • batasi frekuensi munculnya akun baru di papan skor publik jika diperlukan.

Ini membantu tanpa membuat arsitektur terlalu berat.

Bot signup dan abuse prevention tanpa menghancurkan UX

Menambahkan CAPTCHA di semua form sering dianggap solusi cepat, tetapi hasilnya tidak selalu baik. Bot modern bisa cukup efektif melewatinya, sementara user sungguhan terganggu.

Pendekatan berlapis yang lebih masuk akal

  • Honeypot field tersembunyi untuk bot sederhana.
  • Rate limit bertingkat untuk register dan verification resend.
  • Deteksi pola disposable email jika memang relevan untuk model bisnis Anda.
  • Verifikasi email sebelum fitur publik tertentu aktif, misalnya tampil di leaderboard.
  • Challenge tambahan hanya pada traffic berisiko tinggi.

Kapan CAPTCHA masuk akal

CAPTCHA layak dipakai sebagai step-up control, bukan lapisan pertama untuk semua user. Misalnya ketika satu IP membuat banyak akun dalam waktu singkat, atau ketika ada lonjakan signup yang jelas otomatis.

Contoh arsitektur middleware untuk endpoint sensitif

Berikut contoh alur praktis untuk beberapa endpoint penting.

POST /login

request size limit
-> IP/subnet rate limit
-> account identifier rate limit
-> bot signal check
-> input validation & normalization
-> password verification
-> session regenerate
-> secure cookie set
-> audit log

POST /register

request size limit
-> IP rate limit
-> signup risk scoring
-> optional step-up challenge
-> input validation
-> account creation
-> email verification flow
-> audit log

POST /quiz-attempt/start

session/auth check if needed
-> CSRF check
-> input validation for quiz config
-> rate limit
-> create signed/opaque attempt record
-> return attempt_id

POST /leaderboard/submit

session/auth check
-> CSRF check
-> rate limit
-> attempt ownership check
-> attempt status check (active, not expired, not consumed)
-> score verification / recomputation
-> persist result with idempotency guard
-> mark attempt consumed
-> risk scoring / moderation flag

Checklist implementasi hardening

Gunakan daftar ini saat review backend.

Auth dan session

  • Password di-hash dengan algoritma khusus password.
  • Session ID diregenerasi setelah login dan perubahan privilege.
  • Cookie memakai HttpOnly, Secure, dan SameSite yang sesuai.
  • Session lama diinvalidasi setelah reset password atau ganti password.
  • Error message login tidak memudahkan enumerasi akun.

CSRF dan request protection

  • Semua endpoint mutasi dengan cookie session dilindungi CSRF.
  • Origin/Referer divalidasi bila memungkinkan.
  • Batas ukuran body request diterapkan di edge atau reverse proxy.

Input validation

  • Semua endpoint custom quiz memakai allowlist.
  • Field tak dikenal ditolak pada endpoint sensitif.
  • Payload dinormalisasi sebelum disimpan atau dipakai sebagai cache key.
  • Skor akhir tidak dipercaya mentah dari client.

Anti-abuse

  • Rate limiting ada pada login, register, forgot/reset password, submit skor, dan leaderboard.
  • Ada cooldown progresif untuk login gagal berulang.
  • Forgot password dibatasi agar tidak dipakai spam email.
  • Leaderboard memakai model attempt atau mekanisme anti-replay.
  • Bot signup ditahan dengan kontrol berlapis, bukan hanya CAPTCHA.

Secret dan operasional

  • Secret tidak ada di repository dan tidak bocor ke frontend.
  • Log dan error sanitizer mencegah kebocoran token atau API key.
  • Event keamanan penting tercatat: login gagal, reset request, submit skor anomali, spike register.
  • Ada dashboard atau alert untuk lonjakan 4xx/429/5xx pada endpoint sensitif.

Debugging dan observability saat kontrol keamanan mulai aktif

Hardening yang baik tetap bisa gagal jika tidak bisa dioperasikan. Bug paling umum adalah pengguna sah ikut terblokir, tetapi tim tidak tahu di mana.

Apa yang perlu dicatat

  • alasan request ditolak: CSRF gagal, limiter mana yang aktif, attempt invalid, token sudah dipakai,
  • identifier yang aman untuk korelasi, misalnya hash email yang dinormalisasi, bukan email plaintext di semua log,
  • latensi endpoint setelah limiter dan validasi ditambahkan,
  • jumlah event per tipe: login gagal, reset request, signup ditahan, skor ditolak.

Kesalahan observability yang sering terjadi

  • Semua kegagalan hanya tercatat sebagai 400 atau 403 tanpa konteks.
  • Log terlalu detail hingga menyimpan password, token reset, atau cookie.
  • Tidak ada pembeda antara user error dan abuse signal.

Kesalahan umum yang sering lolos review

  • Menyimpan access token di localStorage padahal aplikasi cukup memakai session cookie.
  • Tidak meregenerasi session setelah login.
  • Menganggap SameSite saja sudah cukup tanpa token CSRF.
  • Validasi input hanya di frontend.
  • Memakai rate limit per IP saja.
  • Mengizinkan submit skor tanpa state server-side seperti attempt_id.
  • Mengungkap terlalu banyak detail pada forgot password atau login error.
  • Menganggap leaderboard bukan area sensitif karena “cuma skor game”.

Penutup

Pada produk seperti ToneDear, hardening backend yang efektif biasanya bukan soal menambah lapisan keamanan paling canggih, tetapi memastikan kontrol dasar diterapkan dengan benar dan konsisten. Untuk konteks Hardening Ear Training App: Auth, Session, dan Anti-Abuse, prioritas terbaik adalah session cookie yang aman, CSRF yang benar, validasi input custom quiz yang ketat, rate limiting bertingkat, secret handling yang disiplin, dan model submit skor yang tidak percaya begitu saja pada client.

Jika harus memilih prioritas implementasi, mulai dari ini: perbaiki session dan cookie, tambah rate limit untuk auth flow, validasi semua input latihan dengan allowlist, lalu ubah leaderboard agar berbasis attempt yang diverifikasi server. Empat langkah ini biasanya menutup sebagian besar abuse yang benar-benar terjadi di aplikasi web publik.