# Mengamankan Route Laravel API dengan Sanctum dan Rate Limiting Tingkat Lanjut

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/mengamankan-route-laravel-api-dengan-sanctum-dan-rate-limiting-tingkat-lanjut

---

## 1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02.14 WIB. PagerDuty di sebelah bantal bergetar hebat, memecah keheningan malam dengan nada *high-urgency* yang langsung membuat jantung berdegup kencang. Belum sempat nyawa terkumpul sepenuhnya, layar ponsel sudah dibanjiri notifikasi dari sistem pemantauan: latensi endpoint API melonjak dari rata-rata 45 milidetik menjadi lebih dari 8.500 milidetik, sementara tingkat error HTTP 504 Gateway Timeout merangkak naik menyentuh angka 42%. Di ruang kendali virtual, rekan-rekan *on-call* dari tim frontend mulai melaporkan bahwa aplikasi mobile dan panel dashboard SPA (Single Page Application) lumpuh total, gagal melakukan sinkronisasi data.

Sistem backend kita, monolit berbasis PHP/Laravel yang dibungkus dengan arsitektur RESTful API, tampak sekarat. Padahal, malam itu tidak ada jadwal *deployment* maupun kampanye pemasaran besar-besaran yang seharusnya memicu lonjakan trafik organik. Ada sesuatu yang tidak beres di balik layar, dan sebagai Principal Systems Architect yang bertanggung jawab atas keandalan infrastruktur ini, saya tahu persis bahwa membiarkan server berputar tanpa arah hanya akan berujung pada keruntuhan total *connection pool* database MySQL.

Langkah pertama yang harus diambil bukanlah menebak-nebak, melainkan langsung menerobos masuk ke dalam perut infrastruktur melalui terminal. Dengan jemari yang masih kaku akibat dinginnya AC ruangan, saya membuka sesi SSH ke *load balancer* Nginx dan memantau antrean proses yang sedang berjalan. Apa yang saya temukan di balik layar terminal tersebut ternyata menjadi awal dari sebuah investigasi forensik digital yang membuka mata kita semua tentang rapuhnya sistem autentikasi dan kontrol lalu lintas yang selama ini diandalkan.

## 2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Masuk ke dalam server produksi, komando pertama yang saya eksekusi bukanlah me-restart layanan, melainkan memeriksa denyut nadi server web melalui akses log Nginx secara real-time. Perintah `tail -f /var/log/nginx/api_access.log` langsung memperlihatkan pemandangan yang membuat bulu kuduk berdiri. Ribuan baris log berhamburan dalam hitungan detik, semuanya menghantam endpoint `/api/v1/user/profile` dan `/api/v1/auth/token` dari deretan alamat IP yang berasal dari jaringan *datacenter* komersial tertentu, bukan pengguna akhir yang sah.

> [!WARNING]
> Serangan *credential stuffing* dan *brute force* yang terdistribusi secara masif dapat melumpuhkan server PHP-FPM dalam hitungan menit jika tidak segera diredam pada lapisan *edge* atau web server.

```bash
# Memantau trafik mencurigakan secara real-time pada Nginx access log
sudo tail -n 100 /var/log/nginx/api_access.log | grep -E "POST /api/v1/auth" | awk '{print $1}' | sort | uniq -c | sort -nr
```

Hasil analisis log menunjukkan bahwa satu alamat IP tunggal mampu mengirimkan hingga 350 *request* per detik tanpa membawa token autentikasi yang valid, mencoba menebak kombinasi kredensial secara membabi buta. Lebih parahnya lagi, mekanisme *default* rate limiting bawaan Laravel yang masih mengandalkan *driver* `cache` berbasis file atau tabel database MySQL lokal langsung ambruk. Tabel `cache` di database membengkak, memicu *table lock*, menghabiskan seluruh kuota *max_connections* MySQL, dan menyeret seluruh layanan API ke jurang kematian.

Lonjakan metrik di Grafana menunjukkan grafik penggunaan CPU pada klaster PHP-FPM menyentuh 100%, sementara konsumsi memori Redis melonjak drastis akibat terjangan *query* validasi sesi yang tidak ter-indeks dengan benar. Kita sedang menghadapi serangan DoS (Denial of Service) lapis aplikasi yang memanfaatkan celah lemahnya sistem pembatasan laju akses (*rate limiting*) dan pengelolaan token yang kurang optimal. Dari sinilah investigasi mendalam terhadap akar permasalahan arsitektur dimulai.

## 3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Setelah berhasil mengisolasi trafik anomali tersebut, saya bersama tim melakukan audit menyeluruh terhadap kode sumber backend dan konfigurasi infrastruktur. Ada tiga dosa besar arsitektural yang ditemukan dalam implementasi sistem autentikasi kita sebelumnya, yang jika dibiarkan akan terus menjadi bom waktu bagi kelangsungan bisnis.

*Pertama*, konfigurasi Laravel Sanctum yang digunakan untuk mengamankan SPA dan aplikasi mobile terlalu longgar. Sanctum diatur menggunakan *stateful domain* yang rentan terhadap masalah CORS jika tidak dipetakan dengan presisi, serta mengandalkan token personal (Personal Access Token) tanpa mekanisme *revocation* otomatis yang efisien.

*Kedua*, mekanisme *rate limiting* masih menggunakan *default* penanganan bawaan Laravel yang mengandalkan *driver* cache lokal atau database relasional. Ketika ribuan request masuk secara bersamaan, operasi baca-tulis pada tabel cache database menciptakan *bottleneck* I/O yang sangat parah.

*Ketiga*, tidak adanya sistem *token blacklisting* atau *revocation cache* berbasis memori membuat token yang sudah kedaluwarsa atau dicabut masih harus divalidasi langsung ke database pada setiap siklus *request life-cycle*. Hal ini memperberat beban kerja MySQL secara tidak perlu.

```php
// Contoh implementasi lama yang rapuh: Rate limiting mengandalkan driver database default
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    // Menggunakan cache database lokal yang mudah jebol saat trafik tinggi
    return Limit::perMinute(60)->by($request->ip());
});
```

Transformasi arsitektur menjadi sebuah keniscayaan. Kita harus memindahkan seluruh beban *rate limiting* dan validasi token ke dalam ekosistem memori berkecepatan tinggi menggunakan Redis, serta memperketat konfigurasi Laravel Sanctum agar mampu membedakan dengan tegas antara permintaan dari SPA berbasis Cookie (stateful) dan Mobile App berbasis Bearer Token (stateless).

## 4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Hitungan Menit
 di tengah krisis, setiap detik berarti kerugian finansial dan reputasi. Sebelum merombak total kode di lingkungan *staging*, kita harus memadamkan api yang sedang membakar server produksi saat ini juga. Berikut adalah serangkaian perintah darurat dan penyesuaian konfigurasi kilat yang dieksekusi langsung di server untuk mengembalikan kestabilan sistem dalam waktu kurang dari 60 detik.

Langkah pertama adalah memblokir alamat IP penyerang secara cepat langsung di tingkat web server Nginx menggunakan modul pembatas, sekaligus mengalihkan *rate limiter* Laravel agar langsung menembak klaster Redis yang masih memiliki kapasitas cadangan.

```bash
# Eksekusi darurat: Blokir IP penyerang menggunakan iptables dan reload Nginx
sudo iptables -A INPUT -s 192.0.2.1/32 -j DROP
sudo systemctl reload nginx
```

Selanjutnya, kita memperbarui konfigurasi `.env` dan *service provider* Laravel untuk memastikan *rate limiter* beralih sepenuhnya ke Redis, serta membersihkan koneksi database yang tersangkut (*stuck connections*).

```bash
# Membersihkan koneksi MySQL yang menggantung dan merestart PHP-FPM
mysql -u root -p -e "SHOW PROCESSLIST;" | grep Sleep | awk '{print "KILL " $1 ";\