Belajar ReactJS - Secure Frontend & Auth Patterns

#Pendahuluan

Keamanan frontend sering dianggap remeh, padahal di sinilah data pengguna pertama kali disentuh. Episode 12 membahas pola yang benar untuk autentikasi dan otorisasi di aplikasi React: alur login pada SPA, penyimpanan token yang aman, protecting routes, dan role-based access control.

Di paruh kedua kita membahas ancaman nyata yang menghantui setiap frontend — CSRF dan XSS — serta praktik menangani input pengguna dengan aman. Keamanan bukan fitur tambahan; ini persyaratan dasar aplikasi serius.

#Authentication Patterns untuk SPA

#Alur Login pada Single Page App

Pada SPA, autentikasi umumnya berjalan seperti ini: pengguna kirim kredensial, server mengembalikan token, aplikasi menyimpannya lalu memakainya di setiap request berikutnya:

login -> server verifikasi -> token dikirim -> token disimpan -> token dipakai di header Authorization

Token yang paling umum adalah JWT (JSON Web Token): string berisi header, payload, dan signature yang bisa diverifikasi server tanpa menyimpan sesi. Aplikasi menaruhnya di header Authorization: Bearer <token> pada tiap request.

#JWT, Refresh Tokens, dan Secure Storage

#Access Token dan Refresh Token

Satu token yang berlaku lama berisiko besar jika bocor. Pola yang lebih aman memakai dua token:

• Access token: umur pendek, misalnya 15 menit, dikirim di setiap request.
• Refresh token: umur panjang, hanya dipakai untuk mendapatkan access token baru.

Memakai access token di axios

import axios from "axios"
 
const api = axios.create({
  baseURL: "https://api.example.com",
})
 
api.interceptors.request.use((config) => {
  const token = localStorage.getItem("access_token")
  if (token) config.headers.Authorization = `Bearer ${token}`
  return config
})

Interceptor api.interceptors.request.use((config) => ...) menambahkan header Authorization otomatis ke setiap request. Ketika access token kedaluwarsa, interceptor respons bisa memanggil endpoint refresh untuk memperbaruinya tanpa memaksa pengguna login ulang.

#Secure Storage: localStorage vs HttpOnly Cookie

Ini keputusan keamanan penting:

• localStorage: mudah dibaca JavaScript, sehingga rentan terhadap XSS. Hanya cocok untuk token non-sensitif.
• HttpOnly cookie: tidak bisa diakses JavaScript, jadi aman dari XSS. Harus didukung Secure dan SameSite untuk melawan CSRF.

Untuk aplikasi produksi, pola yang dianjurkan: access token di memory (state React) dan refresh token di HttpOnly cookie. Jangan pernah menaruh token sensitif di localStorage tanpa pertimbangan risiko XSS.

#Protecting Routes dan Role-Based Access Control

#Protecting Routes

Gabungkan pattern route guard episode 9 dengan konteks autentikasi:

Protected route dengan auth context

import { useContext } from "react"
import { Navigate } from "react-router-dom"
import { AuthContext } from "./AuthContext.jsx"
 
function ProtectedRoute({ anak }) {
  const { user } = useContext(AuthContext)
  if (!user) return <Navigate to="/login" replace />
  return anak
}

const { user } = useContext(AuthContext) membaca sesi pengguna. Jika tidak ada, <Navigate to="/login" replace /> mengalihkan ke login. Bungkus route yang sensitif dengan <ProtectedRoute>...</ProtectedRoute>.

#Role-Based Access Control

Tidak semua pengguna punya hak yang sama. RBAC memeriksa peran pengguna sebelum mengizinkan aksi atau halaman:

Pemeriksaan role

function TombolHapus({ user, onClick }) {
  if (user.role !== "admin") return null
  return <button onClick={onClick}>Hapus</button>
}

user.role !== "admin" menyembunyikan tombol dari pengguna non-admin. Ingat aturan emas keamanan: proteksi di frontend hanya untuk UX — otorisasi sebenarnya harus selalu dijalankan di server.

#CSRF, XSS, dan Secure Handling of User Input

#XSS dan React

XSS terjadi saat konten tidak tepercaya dirender sebagai HTML. React mem-escape semua teks secara default — menulis {userInput} aman. Bahaya muncul saat kalian memakai dangerouslySetInnerHTML atau memunculkan teks di atribut dengan cara yang salah:

Memakai dangerouslySetInnerHTML dengan aman

import { DOMPurify } from "dompurify"
 
function Konten({ html }) {
  const bersih = DOMPurify.sanitize(html)
  return <div dangerouslySetInnerHTML={{ __html: bersih }} />
}

DOMPurify.sanitize(html) membersihkan tag berbahaya sebelum dirender. Gunakan dangerouslySetInnerHTML hanya untuk konten yang sudah disanitasi, dan hindari untuk input langsung pengguna.

#CSRF dan HttpOnly Cookie

CSRF terjadi saat browser tanpa sadar mengirim request ke situs kalian dengan cookie sesi. Mitigasi utama:

• Set cookie dengan SameSite=Lax atau Strict.
• Gunakan token CSRF di header untuk request state-changing.
• Jangan pernah mengandalkan cookie sebagai satu-satunya lapisan autentikasi.

npm install dompurify

Perintah npm install dompurify memasang library sanitasi HTML. Selalu sanitasi konten yang berasal dari luar sebelum merendernya — ini salah satu kebiasaan keamanan yang paling berdampak.

#Penutup

Episode 12 membekali kalian keamanan frontend: alur autentikasi SPA dengan JWT, pola access dan refresh token, penyimpanan token yang aman, protecting routes dengan RBAC, serta mitigasi CSRF dan XSS.

Inti yang harus dibawa pulang:

• Autentikasi SPA: login, terima token, kirim di header Authorization.
• JWT dipakai sebagai access token; refresh token memperbarui tanpa login ulang.
• HttpOnly cookie lebih aman dari XSS dibanding localStorage.
• Proteksi frontend hanya untuk UX; otorisasi sejati ada di server.
• React meng-escape teks default; sanitasi konten sebelum memakai dangerouslySetInnerHTML.
• Cookie butuh SameSite dan Secure untuk menahan CSRF.

Di episode 13 selanjutnya kita akan membahas API integration & error handling — mengonsumsi REST dan GraphQL API, fetch policies dengan retries dan retry delays, centralized error handling dengan fallback UI, serta preloading data dan optimistic updates. Integrasi yang tangguh adalah pembeda aplikasi profesional.