Category: Tutorial

Di Belajar Golang dari Nol #26 kita sudah mengatur siapa boleh melakukan apa lewat role dan otorisasi. Server kita sekarang tahu membedakan admin dan kasir. Tapi ada satu lubang yang belum kita tutup rapat. Bagaimana kalau data yang dikirim user itu sendiri yang bermasalah? Email tanpa tanda @. Password satu huruf. Field harga yang tidak pernah dikirim tapi diam-diam terbaca nol. Di bagian ini kita bereskan semuanya secara sistematis. Kalau kamu baru bergabung, mulai dari daftar lengkap seri dulu supaya tidak ada yang terlewat.

Semua Data dari Luar Itu Tersangka

Ini prinsip pertama dan paling penting. Server kamu tidak boleh percaya pada apa pun yang datang dari luar. Body JSON bisa diisi field aneh. Query param bisa berisi angka negatif. Path param bisa berisi string padahal kamu berharap angka. Header bisa dipalsukan. File upload bisa menyamar, seperti yang sudah kita bahas waktu memvalidasi file di bagian 20.

Kenapa harus separanoid itu? Karena request ke API kamu tidak selalu datang dari frontend yang kamu buat. Siapa pun bisa membuka terminal, mengetik perintah curl, dan mengirim apa saja ke endpoint kamu. Validasi di sisi frontend itu bagus untuk pengalaman user, tapi dari sudut pandang server, validasi frontend itu tidak ada. Anggap saja tidak pernah terjadi.

Prinsip kedua: validasi dilakukan di tepi, bukan berserakan. Maksudnya, begitu data masuk lewat handler, langsung periksa di situ. Jangan biarkan data mentah menyebar ke service, repository, lalu baru ketahuan bermasalah saat sudah setengah jalan diproses. Selama seri ini kita sudah beberapa kali menulis validasi kecil di sana-sini. Sekarang kita rapikan jadi satu pola yang konsisten.

Jebakan Decode JSON yang Diam-Diam

Decoder JSON bawaan Go itu sopan. Terlalu sopan, malah. Dia tidak protes kalau ada field yang salah ketik. Coba lihat struct ini.

type ProdukRequest struct {
	Nama  string `json:"nama"`
	Harga int    `json:"harga"`
}

Sekarang bayangkan frontend mengirim body seperti ini, dengan typo di field harga.

{"nama": "Kopi Susu", "hrga": 15000}

Decode berhasil tanpa error. Field hrga diabaikan begitu saja, dan Harga terisi nol karena itu zero value untuk int. Masih ingat konsep zero value dari bagian 5? Di sinilah dia menggigit balik. Produk seharga lima belas ribu tersimpan sebagai produk gratis, dan tidak ada satu pun error yang muncul.

Masalah kedua lebih halus lagi. Kalau Harga bernilai nol, kamu tidak bisa membedakan dua kemungkinan: apakah user memang mengirim nol karena produknya gratis, atau field itu tidak dikirim sama sekali? Keduanya menghasilkan nilai yang sama persis.

Ada tiga senjata untuk menutup jebakan ini. Pertama, DisallowUnknownFields supaya field yang tidak dikenal langsung ditolak. Kedua, pointer untuk membedakan kosong dan nol. Ketiga, batas ukuran body supaya orang tidak bisa mengirim payload raksasa, sama semangatnya dengan batas ukuran file upload di bagian 20.

type ProdukRequest struct {
	Nama  string `json:"nama"`
	Harga *int   `json:"harga"`
}

func decodeJSON(w http.ResponseWriter, r *http.Request, dst any) error {
	r.Body = http.MaxBytesReader(w, r.Body, 1<<20) // maksimal 1 MB
	dec := json.NewDecoder(r.Body)
	dec.DisallowUnknownFields()
	return dec.Decode(dst)
}

Dengan Harga bertipe *int, ceritanya jadi jelas. Kalau field tidak dikirim, nilainya nil. Kalau dikirim nol, nilainya pointer ke angka nol. Dua kondisi yang tadinya menyamar jadi satu, sekarang bisa dibedakan. Dan karena decodeJSON ini kita jadikan helper, semua handler memakai aturan yang sama tanpa harus mengulang kode.

Validasi Manual yang Rapi

Setelah decode berhasil, giliran memeriksa isinya. Pola yang enak dipakai: setiap struct request punya method Validate yang mengembalikan daftar error per field. Bukan satu error gabungan, tapi map yang memetakan nama field ke pesan kesalahannya.

import (
	"net/mail"
	"strings"
)

type RegisterRequest struct {
	Nama     string `json:"nama"`
	Email    string `json:"email"`
	Password string `json:"password"`
}

func (req RegisterRequest) Validate() map[string]string {
	errs := map[string]string{}

	if strings.TrimSpace(req.Nama) == "" {
		errs["nama"] = "nama wajib diisi"
	}
	if _, err := mail.ParseAddress(req.Email); err != nil {
		errs["email"] = "format email tidak valid"
	}
	if len(req.Password) < 8 {
		errs["password"] = "password minimal 8 karakter"
	}

	if len(errs) > 0 {
		return errs
	}
	return nil
}

Kenapa map, bukan error biasa? Karena frontend butuh tahu field mana yang salah supaya bisa menampilkan pesan tepat di bawah kolom isian yang bermasalah. Balasannya kita bungkus dalam JSON dengan status 400.

func kirimErrorValidasi(w http.ResponseWriter, errs map[string]string) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusBadRequest)
	json.NewEncoder(w).Encode(map[string]any{"errors": errs})
}

Hasilnya seperti ini. Satu request, semua kesalahan dilaporkan sekaligus, bukan satu per satu.

{
  "errors": {
    "email": "format email tidak valid",
    "password": "password minimal 8 karakter"
  }
}

Bandingkan dengan API yang hanya membalas “input tidak valid” tanpa penjelasan. User mengisi ulang form sambil menebak-nebak salahnya di mana. Format per field ini kecil usahanya, besar dampaknya.

go-playground/validator, Jalan Singkat yang Populer

Menulis validasi manual untuk tiga field itu ringan. Tapi kalau aplikasimu punya dua puluh struct request dengan aturan mirip-mirip, kode Validate mulai terasa berulang. Di sinilah library go-playground/validator membantu. Aturan ditulis sebagai tag di struct.

import "github.com/go-playground/validator/v10"

type ProdukRequest struct {
	Nama  string `json:"nama" validate:"required,min=3,max=100"`
	Email string `json:"email" validate:"required,email"`
	Stok  int    `json:"stok" validate:"gte=0"`
}

var validate = validator.New()

Tag required menolak nilai kosong, email memeriksa format, min dan max membatasi panjang, gte=0 memastikan angka tidak negatif. Satu baris tag menggantikan beberapa baris if.

Masalahnya, pesan error bawaannya berbahasa mesin. Sesuatu seperti “Field validation for ‘Email’ failed on the ’email’ tag” jelas tidak pantas ditampilkan ke user. Kita terjemahkan sendiri jadi bahasa manusia, sekaligus dipetakan per field seperti pola sebelumnya.

func pesanValidasi(err error) map[string]string {
	errs := map[string]string{}
	for _, e := range err.(validator.ValidationErrors) {
		field := strings.ToLower(e.Field())
		switch e.Tag() {
		case "required":
			errs[field] = field + " wajib diisi"
		case "email":
			errs[field] = "format email tidak valid"
		case "min":
			errs[field] = field + " minimal " + e.Param() + " karakter"
		case "gte":
			errs[field] = field + " tidak boleh kurang dari " + e.Param()
		default:
			errs[field] = field + " tidak valid"
		}
	}
	return errs
}

Lalu kapan cukup manual dan kapan pakai library? Jujur saja: untuk aplikasi kecil dengan sedikit endpoint, validasi manual lebih mudah dibaca dan tidak menambah dependensi. Library mulai terasa manfaatnya saat jumlah struct request banyak dan aturannya standar. Yang penting bukan pilihan alatnya, tapi konsistensinya. Pilih satu pola, pakai di semua endpoint.

Bentuk Data vs Aturan Bisnis

Ada dua jenis validasi yang sering dicampur padahal tempatnya beda. Yang pertama validasi bentuk: apakah email formatnya benar, apakah password cukup panjang, apakah stok berupa angka. Ini urusan handler, karena tidak butuh melihat database atau kondisi sistem.

Yang kedua validasi aturan bisnis: apakah stok masih cukup kalau dikurangi jumlah pesanan, apakah email ini sudah dipakai akun lain, apakah user ini boleh menghapus data itu. Aturan seperti ini butuh konteks, biasanya butuh query ke database, dan tempatnya di layer service, sesuai pembagian tanggung jawab yang kita susun di bagian 16 dan kita praktikkan lagi di bagian 23.

Contoh konkret. “Stok tidak boleh minus” terdengar seperti validasi input, tapi sebenarnya bukan. Angka 5 itu bentuknya valid. Baru setelah service mengecek stok tersisa 3, ketahuan bahwa mengurangi 5 akan membuat stok minus. Handler tidak mungkin tahu itu. Jadi jangan paksakan semua pemeriksaan masuk ke Validate. Bentuk di handler, aturan bisnis di service. Pembagian ini membuat masing-masing lapisan tetap sederhana.

Sanitasi: Bereskan Saat Keluar, Bukan Saat Masuk

Sekarang topik yang sering disalahpahami. Banyak pemula berpikir input berbahaya harus dibersihkan sebelum disimpan, misalnya menghapus semua tag HTML dari nama user. Pendekatan yang lebih sehat justru sebaliknya: simpan apa adanya, lalu escape saat menampilkan.

Sebentar, apa itu XSS? Bayangkan ada user jahil yang mengisi nama dengan potongan kode JavaScript. Kalau aplikasimu menampilkan nama itu di halaman web mentah-mentah, browser pengunjung lain akan menjalankan kode tersebut seolah bagian sah dari situsmu. Kode itu bisa mencuri sesi, membajak akun, atau mengarahkan korban ke situs palsu. Itulah XSS, singkatan dari cross-site scripting: skrip orang lain yang menumpang lewat data.

Kabar baiknya, html/template yang kita pakai sejak bagian 21 sudah melakukan escaping otomatis. Setiap nilai yang dirender lewat template itu diubah jadi teks aman, sehingga kode jahat tampil sebagai tulisan biasa, bukan dieksekusi. Ini alasan yang sama kenapa kita pakai placeholder untuk SQL di bagian 12: biarkan alat yang tepat menangani escaping, jangan tempel string sendiri.

Lalu kenapa API yang hanya membalas JSON tetap perlu peduli? Karena browser kadang sok tahu. Kalau response tidak diberi Content-Type yang jelas, sebagian browser mencoba menebak jenis kontennya, dan tebakan itu bisa berujung pada JSON yang diperlakukan sebagai HTML. Pastikan setiap response JSON menyertakan header Content-Type: application/json, seperti yang sudah kita lakukan di helper tadi. Murah, satu baris, dan menutup satu pintu serangan.

Normalisasi, Validasi Kecil yang Mencegah Bug Besar

Ada satu langkah lagi sebelum data disimpan: normalisasi. Ini bukan soal menolak data, tapi merapikan bentuknya supaya konsisten. Tiga contoh yang paling sering menyelamatkan saya.

Pertama, strings.TrimSpace untuk semua input teks. Spasi tak sengaja di akhir nama atau email itu sangat umum, apalagi dari keyboard HP yang suka menambah spasi setelah autocomplete.

Kedua, email di-lowercase sebelum dicek unik. Waktu membangun register di bagian 25, kita menyimpan email sebagai identitas login. Kalau Budi@contoh.com dan budi@contoh.com dianggap dua akun berbeda, user akan bingung kenapa tidak bisa login padahal merasa sudah daftar. Normalkan dulu, baru bandingkan.

Ketiga, nomor HP dinormalkan ke awalan 62. User Indonesia menulis nomor dengan segala gaya: 0812, +62812, 62812, kadang pakai spasi atau strip. Kalau disimpan apa adanya, fitur kirim WhatsApp atau pencarian nomor akan kacau.

func normalisasiHP(hp string) string {
	hp = strings.TrimSpace(hp)
	hp = strings.ReplaceAll(hp, " ", "")
	hp = strings.ReplaceAll(hp, "-", "")

	switch {
	case strings.HasPrefix(hp, "+62"):
		return hp[1:]
	case strings.HasPrefix(hp, "0"):
		return "62" + hp[1:]
	}
	return hp
}

Letakkan normalisasi tepat sebelum validasi. Urutannya: decode, normalisasi, validasi bentuk, baru serahkan ke service. Dengan begitu validasi bekerja pada data yang sudah rapi.

Latihan: Memperkuat Endpoint Register

Sekarang kita gabungkan semuanya ke endpoint register yang kita buat di bagian 25. Dulu validasinya masih seadanya. Versi barunya membatasi body, menolak field asing, menormalkan input, lalu melaporkan error per field.

func (h *AuthHandler) Register(w http.ResponseWriter, r *http.Request) {
	var req RegisterRequest
	if err := decodeJSON(w, r, &req); err != nil {
		kirimErrorValidasi(w, map[string]string{
			"body": "format JSON tidak valid atau ada field yang tidak dikenal",
		})
		return
	}

	// normalisasi dulu, baru validasi
	req.Nama = strings.TrimSpace(req.Nama)
	req.Email = strings.ToLower(strings.TrimSpace(req.Email))

	if errs := req.Validate(); errs != nil {
		kirimErrorValidasi(w, errs)
		return
	}

	user, err := h.service.Register(r.Context(), req)
	if err != nil {
		// aturan bisnis, misalnya email sudah terdaftar,
		// ditangani service seperti di bagian 25
		kirimErrorValidasi(w, map[string]string{"email": err.Error()})
		return
	}

	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(user)
}

Uji dengan curl. Pertama, request yang benar.

curl -X POST http://localhost:8080/register \
  -H "Content-Type: application/json" \
  -d '{"nama":"Budi Santoso","email":"Budi@contoh.com","password":"rahasia123"}'

Server membalas 201, dan email tersimpan sebagai budi@contoh.com berkat normalisasi. Sekarang tiga variasi gagal. Password terlalu pendek dan nama kosong sekaligus.

curl -X POST http://localhost:8080/register \
  -H "Content-Type: application/json" \
  -d '{"nama":"  ","email":"budi@contoh.com","password":"123"}'

Balasan 400 dengan dua error sekaligus: nama wajib diisi, password minimal 8 karakter. Perhatikan nama berisi spasi saja tetap tertangkap karena TrimSpace berjalan sebelum validasi. Berikutnya, email rusak.

curl -X POST http://localhost:8080/register \
  -H "Content-Type: application/json" \
  -d '{"nama":"Budi","email":"bukan-email","password":"rahasia123"}'

Balasan 400 dengan pesan format email tidak valid. Terakhir, field yang salah ketik.

curl -X POST http://localhost:8080/register \
  -H "Content-Type: application/json" \
  -d '{"nama":"Budi","emial":"budi@contoh.com","password":"rahasia123"}'

Tanpa DisallowUnknownFields, typo emial akan lolos diam-diam dan email tersimpan kosong. Sekarang decoder langsung menolak, dan frontend tahu ada yang salah sejak detik pertama, bukan setelah data aneh masuk database.

Penutup

Hari ini kita menutup satu lubang besar dengan pola yang konsisten: semua data dari luar itu tersangka sampai terbukti valid. Decode dengan ketat, normalisasi, validasi bentuk di handler, aturan bisnis di service, escape saat menampilkan. Endpoint register kita sekarang jauh lebih tahan banting menghadapi input liar.

Backend kita makin lengkap, tapi ada satu masalah klasik yang belum tersentuh: frontend sering harus menebak bentuk request dan response API kita. Di bagian 28 kita bahas “Dokumentasi API dengan OpenAPI: Biar Frontend Tidak Menebak”.

Kalau kamu sedang membangun aplikasi untuk bisnismu dan ingin backend yang aman menangani input user sejak hari pertama, tim kami bisa membantu lewat jasa pengembangan sistem aplikasi. Sampai jumpa di bagian berikutnya.

Di Belajar Golang dari Nol #25 kita sudah membangun register, login, dan JWT. Server sekarang tahu siapa yang sedang mengakses API. UserID sudah tersimpan rapi di context. Tapi tahu siapa dia itu baru setengah cerita. Pertanyaan berikutnya: dia boleh melakukan apa? Itulah otorisasi, dan itu yang kita bahas di bagian ini. Kalau kamu baru bergabung, cek dulu daftar lengkap seri supaya tidak ada yang terlewat.

Dua Cerita yang Sering Kejadian

Cerita pertama. Sebuah aplikasi kasir sudah punya login. Semua pegawai punya akun. Suatu hari pemilik toko sadar ada transaksi yang hilang dari laporan. Setelah ditelusuri, ternyata salah satu kasir menghapus transaksi lewat API. Bukan karena dia hacker. Endpoint hapus transaksi memang bisa diakses siapa saja yang sudah login. Sistem cuma bertanya “kamu siapa”, tidak pernah bertanya “kamu boleh tidak”.

Cerita kedua lebih halus. Sebuah API punya endpoint GET /orders/17. User dengan pesanan nomor 17 bisa melihat pesanannya. Lalu dia iseng mengganti angka di URL jadi 18. Muncul pesanan orang lain, lengkap dengan nama dan alamat. Dia coba PUT /users/9 dengan ID user lain, dan berhasil mengubah data orang itu. Ini celah klasik yang punya nama: IDOR, Insecure Direct Object Reference. Artinya sederhana: server memberi akses ke objek hanya berdasarkan ID yang diketik klien, tanpa mengecek apakah objek itu memang milik dia.

Dua cerita ini masalah bisnis, bukan cuma masalah teknis. Versi non-teknisnya pernah kami tulis di artikel hak akses di sistem bisnis kalau kamu mau menjelaskan ini ke atasan atau klien.

Dua Level Otorisasi yang Wajib Dibedakan

Sebelum menulis kode, luruskan dulu konsepnya. Otorisasi punya dua level yang berbeda, dan keduanya harus dicek.

Pertama, otorisasi berbasis peran. Admin boleh menghapus produk, kasir tidak. Ini menjawab pertanyaan “jabatan kamu mengizinkan aksi ini atau tidak”. Cek peran cocok ditaruh di middleware karena aturannya melekat pada route, bukan pada data.

Kedua, otorisasi berbasis kepemilikan. User boleh mengedit profil, tapi hanya profilnya sendiri. User boleh membatalkan pesanan, tapi hanya pesanan miliknya. Ini menjawab pertanyaan “objek ini punya kamu atau bukan”.

Banyak bug keamanan lahir karena developer hanya mengerjakan level pertama. Route sudah dilindungi middleware role, terasa aman, lalu cek kepemilikan dilupakan. Hasilnya persis cerita kedua tadi: semua user sah bisa saling mengutak-atik data lewat menebak ID. Ingat prinsip ini: cek peran dan cek kepemilikan itu dua pagar yang berbeda. Satu pagar tidak menggantikan pagar yang lain.

Menambah Kolom Role di Tabel Users

Kita mulai dari database. Tabel users dari bagian sebelumnya belum punya kolom role. Tambahkan lewat migrasi baru, dengan cara yang sama seperti yang kita pelajari di bagian 23. Buat dua file migrasi:

-- 000006_add_role_to_users.up.sql
ALTER TABLE users ADD COLUMN role VARCHAR(20) NOT NULL DEFAULT 'user';

-- 000006_add_role_to_users.down.sql
ALTER TABLE users DROP COLUMN role;

Default 'user' penting. Semua akun lama otomatis jadi user biasa. Tidak ada akun yang tiba-tiba jadi admin. Untuk membuat admin pertama, ubah manual lewat SQL:

UPDATE users SET role = 'admin' WHERE email = 'owner@toko.com';

Jangan buat endpoint register yang menerima field role dari klien. Kalau klien bisa mendaftar sambil memilih rolenya sendiri, semua pagar yang kita bangun setelah ini percuma.

Membawa Role di Dalam JWT

Sekarang update proses login dari bagian 25. Saat token dibuat, ikutkan role sebagai claim:

claims := jwt.MapClaims{
    "sub":  user.ID,
    "role": user.Role,
    "exp":  time.Now().Add(15 * time.Minute).Unix(),
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
signed, err := token.SignedString([]byte(secretKey))

Lalu di middleware autentikasi yang sudah kita punya, tambahkan satu baris untuk menaruh role di context, bersebelahan dengan userID:

c.Set("userID", int(claims["sub"].(float64)))
c.Set("role", claims["role"].(string))

Dengan begitu setiap handler dan middleware setelahnya bisa membaca role tanpa query ke database lagi.

Middleware RequireRole

Ini pagar pertama kita. Middleware yang menerima daftar role yang diizinkan, lalu menolak sisanya:

func RequireRole(roles ...string) gin.HandlerFunc {
    return func(c *gin.Context) {
        roleVal, ok := c.Get("role")
        if !ok {
            c.AbortWithStatusJSON(http.StatusUnauthorized,
                gin.H{"error": "silakan login dulu"})
            return
        }

        userRole := roleVal.(string)
        for _, allowed := range roles {
            if userRole == allowed {
                c.Next()
                return
            }
        }

        c.AbortWithStatusJSON(http.StatusForbidden,
            gin.H{"error": "kamu tidak punya akses untuk aksi ini"})
    }
}

Perhatikan dua status code yang berbeda di situ. Ini sering tertukar, jadi kita bedah pelan-pelan. 401 Unauthorized artinya “saya tidak tahu kamu siapa”. Token tidak ada, atau tidak valid. Solusinya login. 403 Forbidden artinya “saya tahu kamu siapa, dan kamu tetap tidak boleh”. Login ulang tidak akan menolong, karena masalahnya bukan identitas, tapi izin. Klien yang menerima 401 harus diarahkan ke halaman login. Klien yang menerima 403 cukup diberi pesan bahwa aksinya tidak diizinkan.

Pemasangannya per route, ditumpuk setelah middleware autentikasi:

products := r.Group("/products")
products.GET("", h.ListProducts)
products.GET("/:id", h.GetProduct)

adminProducts := r.Group("/products")
adminProducts.Use(AuthMiddleware(), RequireRole("admin"))
adminProducts.POST("", h.CreateProduct)
adminProducts.PUT("/:id", h.UpdateProduct)
adminProducts.DELETE("/:id", h.DeleteProduct)

Urutan middleware penting. AuthMiddleware harus jalan dulu supaya role sudah ada di context saat RequireRole membacanya. Route baca tetap terbuka untuk semua orang, route tulis hanya untuk admin.

Cek Kepemilikan di Service Layer

Sekarang pagar kedua. Kenapa tidak di middleware juga? Karena middleware tidak tahu apa-apa soal data. Untuk memutuskan “pesanan 17 ini milik user 4 atau bukan”, kita harus mengambil pesanan itu dari database dulu. Itu urusan service layer. Middleware hanya kenal request, service yang kenal data.

Contoh pertama, update profil. User hanya boleh mengubah profilnya sendiri:

var ErrForbidden = errors.New("tidak berhak mengakses data ini")

func (s *UserService) UpdateProfile(ctx context.Context,
    targetID, requesterID int, input UpdateProfileInput) error {

    if targetID != requesterID {
        return ErrForbidden
    }
    return s.repo.Update(ctx, targetID, input)
}

Contoh kedua, hapus pesanan. Di sini datanya harus diambil dulu:

func (s *OrderService) Delete(ctx context.Context,
    orderID, requesterID int, role string) error {

    order, err := s.repo.FindByID(ctx, orderID)
    if err != nil {
        return err
    }

    isOwner := order.UserID == requesterID
    isAdmin := role == "admin"

    if !isOwner && !isAdmin {
        return ErrForbidden
    }

    if isAdmin && !isOwner {
        s.audit.Log(ctx, requesterID, "delete_order", orderID)
    }

    return s.repo.Delete(ctx, orderID)
}

Di handler, petakan ErrForbidden ke status 403 dengan errors.Is, pola yang sudah kita pakai sejak membahas error handling. Ambil requesterID dan role dari context, jangan pernah dari body atau query. ID di URL adalah objek yang mau diakses. ID di context adalah siapa yang mengakses. Jangan sampai tertukar, karena menukar keduanya itulah yang menciptakan IDOR.

Admin Override yang Tercatat

Lihat lagi kode di atas. Admin boleh menghapus pesanan siapa pun. Kadang memang perlu, misalnya membersihkan pesanan bermasalah. Tapi kekuasaan tanpa catatan itu berbahaya, bahkan untuk admin yang jujur sekalipun. Ketika ada data hilang, pertanyaan pertama pemilik bisnis selalu sama: siapa yang menghapus, kapan, dan kenapa.

Karena itu setiap kali admin menyentuh data milik orang lain, tulis ke log audit: siapa pelakunya, aksi apa, objek mana, jam berapa. Konsepnya sama dengan jejak audit yang kita bahas di bagian 18, sekarang tinggal dipakai di titik yang tepat. Satu baris s.audit.Log hari ini bisa menyelamatkan investigasi berjam-jam di kemudian hari.

Jangan Percaya Klien, Tapi Kenali Batas JWT

Mungkin kamu bertanya: role kan disimpan di JWT, dan JWT ada di tangan klien. Bagaimana kalau user mengedit tokennya sendiri dan mengganti role jadi admin?

Tenang. JWT ditandatangani dengan secret yang hanya diketahui server. Begitu payload diubah satu karakter saja, signature tidak cocok lagi dan token ditolak saat verifikasi. Selama secret tidak bocor, isi klaim aman dari manipulasi.

Tapi ada batas lain yang jujur harus diakui: klaim itu potret saat login, bukan data langsung dari database. Bayangkan seorang admin dicabut haknya siang ini. Token lama di tangannya masih berbunyi role: admin dan tetap valid sampai kadaluarsa. Selama sisa umur token itu, dia masih bisa lewat pagar RequireRole("admin").

Ada dua mitigasi yang umum, dan keduanya punya harga. Pertama, expiry pendek, misalnya 15 menit seperti contoh kita, dipasangkan dengan refresh token. Perubahan role paling lambat berlaku 15 menit kemudian. Harganya: alur refresh lebih rumit. Kedua, untuk aksi yang sangat sensitif seperti menghapus user atau mengubah role orang lain, abaikan klaim dan cek role langsung ke database saat itu juga. Harganya: satu query ekstra per request. Pilihan yang masuk akal untuk kebanyakan aplikasi: expiry pendek untuk umum, cek database khusus untuk endpoint paling berbahaya. Tidak ada jawaban gratis di sini, yang penting kamu memilih dengan sadar.

Latihan: API Produk dan Pesanan

Waktunya merangkai semua jadi satu. Susun route seperti ini:

r := gin.Default()

// publik: siapa pun boleh baca produk
r.GET("/products", h.ListProducts)
r.GET("/products/:id", h.GetProduct)

// admin: CRUD penuh produk
admin := r.Group("/products")
admin.Use(AuthMiddleware(), RequireRole("admin"))
admin.POST("", h.CreateProduct)
admin.PUT("/:id", h.UpdateProduct)
admin.DELETE("/:id", h.DeleteProduct)

// user login: pesanan dengan cek kepemilikan di service
orders := r.Group("/orders")
orders.Use(AuthMiddleware())
orders.POST("", h.CreateOrder)
orders.GET("/:id", h.GetOrder)
orders.DELETE("/:id", h.DeleteOrder)

Siapkan tiga kondisi untuk menguji: token admin, token user biasa, dan tanpa token. Contoh dua di antaranya:

curl -i -X DELETE http://localhost:8080/products/3 \
  -H "Authorization: Bearer $TOKEN_ADMIN"

curl -i -X DELETE http://localhost:8080/products/3 \
  -H "Authorization: Bearer $TOKEN_USER"

Lalu cocokkan hasilnya dengan matriks ini. Kalau ada satu sel yang meleset, berarti ada pagar yang bocor:

Endpoint                  Admin   User    Anon
GET    /products          200     200     200
POST   /products          201     403     401
PUT    /products/:id      200     403     401
DELETE /products/:id      204     403     401
GET    /orders/:id        200     200*    401
DELETE /orders/:id        204**   204*    401

*  hanya untuk pesanan miliknya sendiri,
   pesanan orang lain harus 403
** aksi admin atas pesanan orang lain
   harus tercatat di log audit

Uji juga skenario IDOR secara sengaja. Login sebagai user A, buat pesanan, catat ID-nya. Login sebagai user B, lalu coba GET dan DELETE pesanan milik A. Kalau jawabannya bukan 403, kembali ke service layer dan periksa cek kepemilikannya. Matriks yang lolos penuh artinya dua pagar kita sudah berdiri: peran di middleware, kepemilikan di service.

Penutup

API kita sekarang tidak cuma tahu siapa yang datang, tapi juga tegas soal siapa boleh apa. Peran dicek di middleware, kepemilikan dicek di service, dan aksi admin atas data orang lain selalu meninggalkan jejak. Tapi masih ada satu pintu yang belum kita jaga: data yang dikirim klien itu sendiri. Di bagian 27 kita bahas “Validasi Input: Jangan Percaya Data dari Luar”.

Pola role dan hak akses seperti ini juga yang kami pasang di setiap proyek aplikasi bisnis, dari sistem kasir sampai manajemen gudang. Kalau bisnismu butuh sistem aplikasi dengan pengaturan hak akses yang rapi, tim Arrazy siap bantu merancangnya.

Di Belajar Golang dari Nol #24 kita mempercepat API dengan caching Redis. API kita sekarang cepat, punya database rapi, dan punya middleware. Tapi ada satu lubang besar. Semua orang yang tahu API key statis dari bagian 13 bisa mengakses semua data. Server tidak tahu siapa yang sedang memakai API. Di bagian ini kita tutup lubang itu. Kita bangun autentikasi user sungguhan dengan register, login, dan JWT. Kalau kamu baru bergabung, cek dulu daftar lengkap seri supaya tidak ada bagian yang terlewat.

Autentikasi vs Otorisasi, Jangan Tertukar

Dua istilah ini sering dicampur, padahal beda. Autentikasi menjawab pertanyaan “kamu siapa”. Otorisasi menjawab pertanyaan “kamu boleh apa”. Urutannya selalu autentikasi dulu, baru otorisasi. Server harus tahu identitasmu sebelum bisa memutuskan hakmu.

API key statis di bagian 13 sebenarnya autentikasi juga, tapi levelnya aplikasi, bukan user. Semua pemegang key dianggap orang yang sama. Sekarang kita naik level. Setiap user punya akun sendiri, dan server tahu persis siapa yang mengirim tiap request. Bagian ini fokus ke autentikasi saja. Otorisasi kita bahas di bagian berikutnya.

Tabel Users Lewat Migrasi

Kita mulai dari database. Sesuai kebiasaan sejak bagian 23, perubahan skema selalu lewat file migrasi, bukan SQL manual di terminal. Buat sepasang file migrasi baru dengan nomor urut berikutnya di proyekmu.

Isi file up:

-- 000004_create_users.up.sql
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    password_hash TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Dan file down untuk jalan mundurnya:

-- 000004_create_users.down.sql
DROP TABLE users;

Perhatikan nama kolomnya: password_hash, bukan password. Ini disengaja. Password tidak pernah disimpan mentah di database. Tidak boleh, dalam kondisi apa pun. Kalau database bocor dan password tersimpan mentah, semua akun user langsung jatuh, termasuk akun mereka di layanan lain yang memakai password sama. Yang kita simpan hanya hasil hash, yaitu sidik jari matematis yang tidak bisa dibalik jadi password asli.

Jalankan migrasinya seperti biasa dengan migrate -path ./migrations -database "$DATABASE_URL" up.

Hash Password dengan Bcrypt

Untuk hashing kita pakai bcrypt dari paket resmi Go. Pasang dulu:

go get golang.org/x/crypto/bcrypt

Kenapa bukan MD5 atau SHA-256? Karena keduanya dirancang untuk cepat. Cepat itu bagus untuk checksum file, tapi bencana untuk password. Penyerang yang mencuri database bisa menebak jutaan kombinasi per detik dengan hash yang cepat. Bcrypt sengaja dibuat lambat, sekitar puluhan milidetik per hash. Untuk satu kali login, lambatnya tidak terasa. Untuk penyerang yang harus mencoba miliaran tebakan, lambat itu jadi tembok. Jadi lambat di sini bukan kelemahan, justru fitur utamanya. Bonusnya, bcrypt otomatis menambahkan salt, jadi dua user dengan password sama tetap punya hash berbeda.

Kita cuma butuh dua fungsi:

package main

import "golang.org/x/crypto/bcrypt"

func hashPassword(password string) (string, error) {
	hash, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
	if err != nil {
		return "", err
	}
	return string(hash), nil
}

func cocokkanPassword(hash, password string) bool {
	err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password))
	return err == nil
}

GenerateFromPassword dipakai saat register. CompareHashAndPassword dipakai saat login. Kita tidak pernah membandingkan string password secara langsung. Biarkan bcrypt yang menghitung apakah password yang dikirim cocok dengan hash di database.

Endpoint Register

Sekarang endpoint pertama. Alurnya: terima email dan password, validasi, hash, simpan.

type authRequest struct {
	Email    string `json:"email"`
	Password string `json:"password"`
}

func (s *Server) handleRegister(w http.ResponseWriter, r *http.Request) {
	var req authRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		http.Error(w, "body tidak valid", http.StatusBadRequest)
		return
	}

	req.Email = strings.ToLower(strings.TrimSpace(req.Email))
	if _, err := mail.ParseAddress(req.Email); err != nil {
		http.Error(w, "format email tidak valid", http.StatusBadRequest)
		return
	}
	if len(req.Password) < 8 {
		http.Error(w, "password minimal 8 karakter", http.StatusBadRequest)
		return
	}

	hash, err := hashPassword(req.Password)
	if err != nil {
		http.Error(w, "terjadi kesalahan server", http.StatusInternalServerError)
		return
	}

	_, err = s.db.ExecContext(r.Context(),
		"INSERT INTO users (email, password_hash) VALUES ($1, $2)",
		req.Email, hash)
	if err != nil {
		http.Error(w, "registrasi tidak dapat diproses", http.StatusBadRequest)
		return
	}

	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(map[string]string{"pesan": "registrasi berhasil"})
}

Ada satu keputusan keamanan yang halus di sini. Saat email sudah terdaftar, constraint UNIQUE membuat insert gagal, dan kita membalas dengan pesan generik “registrasi tidak dapat diproses”. Kenapa tidak jujur bilang “email sudah terdaftar”? Karena pesan sedetail itu bisa dipakai penyerang untuk memetakan siapa saja yang punya akun di sistemmu. Teknik ini disebut user enumeration. Penyerang cukup mencoba ribuan email dan mencatat mana yang ditolak. Pesan generik menutup celah itu. Untuk aplikasi internal kamu boleh lebih longgar, tapi biasakan pola aman sejak awal.

Kenalan dengan JWT

Register beres. Sekarang bagian menariknya: bagaimana server mengenali user di request berikutnya?

Cara klasik adalah session. Server menyimpan catatan “user 42 sedang login” di memori atau database, lalu memberi browser sebuah cookie berisi ID session. Cara ini bekerja, tapi server harus menyimpan dan mencari catatan itu di setiap request.

JWT, singkatan dari JSON Web Token, memakai pendekatan lain. Bayangkan tiket konser yang ditandatangani panitia. Di tiket tertulis namamu dan tanggal berlakunya. Petugas di pintu tidak perlu menelepon kantor pusat untuk mengecek daftar pembeli. Dia cukup memeriksa tanda tangannya asli atau tidak. Kalau asli, isi tiket dipercaya. JWT persis seperti itu. Token berisi klaim tentang user, ditandatangani dengan kunci rahasia server, dan server bisa memverifikasinya tanpa menyimpan session sama sekali.

Bentuk JWT adalah tiga bagian yang dipisah titik: header.payload.signature. Header berisi jenis algoritma. Payload berisi klaim, misalnya ID user dan waktu kadaluarsa. Signature adalah tanda tangan kriptografis atas dua bagian pertama. Kalau ada satu karakter payload yang diubah, tanda tangan tidak akan cocok lagi dan server menolak token itu.

Supaya adil, kita bahas juga minusnya. Pertama, JWT tidak bisa dicabut sebelum kadaluarsa. Server tidak menyimpan daftar token aktif, jadi token yang sudah terbit akan tetap valid sampai exp lewat, meskipun usernya menekan tombol logout. Kedua, payload hanya di-encode dengan base64, bukan dienkripsi. Siapa pun yang memegang token bisa membaca isinya. Jadi jangan pernah menaruh data sensitif seperti password atau nomor identitas di payload. Cukup ID user dan waktu kadaluarsa.

Login dan Pembuatan Token

Kita pakai library yang paling umum di ekosistem Go:

go get github.com/golang-jwt/jwt/v5

Kunci rahasia diambil dari environment variable, sama seperti konfigurasi database kita selama ini. Jangan tulis langsung di kode.

var jwtSecret = []byte(os.Getenv("JWT_SECRET"))

func buatToken(userID int64) (string, error) {
	claims := jwt.MapClaims{
		"sub": strconv.FormatInt(userID, 10),
		"iat": time.Now().Unix(),
		"exp": time.Now().Add(24 * time.Hour).Unix(),
	}
	token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
	return token.SignedString(jwtSecret)
}

Klaim sub alias subject berisi ID user. Klaim exp membuat token hangus otomatis setelah 24 jam. Handler loginnya:

func (s *Server) handleLogin(w http.ResponseWriter, r *http.Request) {
	var req authRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		http.Error(w, "body tidak valid", http.StatusBadRequest)
		return
	}
	req.Email = strings.ToLower(strings.TrimSpace(req.Email))

	var id int64
	var hash string
	err := s.db.QueryRowContext(r.Context(),
		"SELECT id, password_hash FROM users WHERE email = $1",
		req.Email).Scan(&id, &hash)
	if err != nil || !cocokkanPassword(hash, req.Password) {
		http.Error(w, "email atau password salah", http.StatusUnauthorized)
		return
	}

	tokenString, err := buatToken(id)
	if err != nil {
		http.Error(w, "terjadi kesalahan server", http.StatusInternalServerError)
		return
	}

	json.NewEncoder(w).Encode(map[string]string{"token": tokenString})
}

Perhatikan lagi pesan errornya. Email tidak ketemu dan password salah dibalas dengan kalimat yang sama persis. Alasannya sama dengan register tadi: jangan beri petunjuk gratis ke penyerang.

Middleware JWT Menggantikan API Key

Di bagian 13 kita membuat middleware yang mengecek API key statis dari header. Sekarang middleware itu kita pensiunkan dan ganti dengan pemeriksa JWT. Polanya masih sama dengan middleware request ID di bagian 18: periksa request, taruh data di context, teruskan ke handler berikutnya.

type contextKey string

const kunciUserID contextKey = "userID"

func middlewareJWT(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		header := r.Header.Get("Authorization")
		tokenString, ok := strings.CutPrefix(header, "Bearer ")
		if !ok || tokenString == "" {
			http.Error(w, "token tidak ditemukan", http.StatusUnauthorized)
			return
		}

		token, err := jwt.Parse(tokenString, func(t *jwt.Token) (any, error) {
			if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
				return nil, errors.New("metode tanda tangan tidak dikenal")
			}
			return jwtSecret, nil
		})
		if err != nil || !token.Valid {
			http.Error(w, "token tidak valid atau kadaluarsa", http.StatusUnauthorized)
			return
		}

		sub, err := token.Claims.GetSubject()
		if err != nil || sub == "" {
			http.Error(w, "token tidak valid", http.StatusUnauthorized)
			return
		}

		ctx := context.WithValue(r.Context(), kunciUserID, sub)
		next.ServeHTTP(w, r.WithContext(ctx))
	})
}

Tiga hal yang dicek middleware ini. Pertama, header Authorization harus berformat Bearer token. Kedua, tanda tangan harus valid dan algoritmanya harus HMAC, bukan algoritma lain yang diselundupkan penyerang. Ketiga, jwt.Parse otomatis menolak token yang exp nya sudah lewat. Kalau semua lolos, ID user masuk ke context dan handler di belakangnya tinggal membaca.

Handler profil yang membaca userID dari context:

func (s *Server) handleProfil(w http.ResponseWriter, r *http.Request) {
	userID, _ := r.Context().Value(kunciUserID).(string)

	var email string
	var createdAt time.Time
	err := s.db.QueryRowContext(r.Context(),
		"SELECT email, created_at FROM users WHERE id = $1",
		userID).Scan(&email, &createdAt)
	if err != nil {
		http.Error(w, "user tidak ditemukan", http.StatusNotFound)
		return
	}

	json.NewEncoder(w).Encode(map[string]any{
		"id":        userID,
		"email":     email,
		"terdaftar": createdAt,
	})
}

Terakhir, daftarkan semua route. Register dan login terbuka, profil dilindungi middleware:

mux := http.NewServeMux()
mux.HandleFunc("POST /register", s.handleRegister)
mux.HandleFunc("POST /login", s.handleLogin)
mux.Handle("GET /profil", middlewareJWT(http.HandlerFunc(s.handleProfil)))

Praktik Aman yang Wajib Kamu Pegang

Sebelum lanjut ke latihan, catat empat aturan main ini.

Pertama, secret harus panjang dan acak. Minimal 32 byte. Bangkitkan sekali dengan openssl rand -base64 32 lalu simpan di environment variable. Secret pendek seperti “rahasia123” bisa ditebak dengan brute force, dan siapa pun yang tahu secret bisa memalsukan token atas nama user mana saja.

Kedua, HTTPS wajib di production. Token dikirim di header pada setiap request. Tanpa TLS yang sudah kita siapkan di bagian 15, token bisa dibaca siapa saja yang mengintip jaringan, dan mereka langsung bisa menyamar jadi usermu.

Ketiga, buat expiry pendek. Contoh kita memakai 24 jam supaya enak dicoba, tapi di production banyak tim memakai 15 sampai 60 menit. Supaya user tidak perlu login ulang terus, biasanya ada token kedua bernama refresh token, yang berumur lebih panjang dan disimpan server, khusus untuk menukar access token baru. Konsepnya cukup kamu kenal dulu, implementasi penuhnya di luar cakupan bagian ini.

Keempat, jangan pernah menulis token ke log. Token di log sama bahayanya dengan password di log. Kalau perlu debugging, log kan user ID nya saja.

Latihan: Uji Alur Lengkapnya

Jalankan server, lalu uji tiga endpoint tadi dengan curl. Pertama register:

curl -X POST http://localhost:8080/register \
  -H "Content-Type: application/json" \
  -d '{"email":"budi@contoh.com","password":"rahasiabanget"}'

{"pesan":"registrasi berhasil"}

Lalu login untuk mendapatkan token:

curl -X POST http://localhost:8080/login \
  -H "Content-Type: application/json" \
  -d '{"email":"budi@contoh.com","password":"rahasiabanget"}'

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3d..."}

Simpan token itu, lalu akses profil dengan menyertakannya di header:

TOKEN="tempel-token-kamu-di-sini"

curl http://localhost:8080/profil \
  -H "Authorization: Bearer $TOKEN"

{"id":"1","email":"budi@contoh.com","terdaftar":"2026-07-27T09:15:02Z"}

Terakhir, buktikan penjagaannya bekerja. Akses tanpa token:

curl -i http://localhost:8080/profil

HTTP/1.1 401 Unauthorized

token tidak ditemukan

Dapat 200 saat bawa token dan 401 saat tidak, berarti autentikasimu sudah jalan. Coba juga skenario lain: register dengan email yang sama dua kali, login dengan password salah, dan akses profil dengan token yang kamu ubah satu hurufnya. Perhatikan responsnya, lalu telusuri di kode kenapa hasilnya begitu.

Penutup

API kita akhirnya kenal usernya. Password tersimpan aman sebagai hash bcrypt, login menghasilkan JWT bertanda tangan, dan middleware memastikan hanya pemegang token valid yang bisa masuk. Fondasi ini yang dipakai hampir semua API modern, dari aplikasi kasir sampai sistem informasi sekolah.

Tapi ingat, server baru tahu kamu siapa. Dia belum bisa membedakan admin dari user biasa. Itu ranah otorisasi, dan kita bahas di bagian 26: Role dan Otorisasi: Membatasi Siapa Boleh Apa.

Kalau kamu sedang membangun aplikasi dengan kebutuhan login, role, dan keamanan data yang serius, tim Arrazy bisa bantu lewat jasa pembuatan sistem aplikasi. Sampai jumpa di bagian berikutnya.