Validasi Header dan Rotasi Secret untuk Auth API di CodeIgniter 4

Dalam konteks API Auth, ancaman seperti CSRF, token leakage, dan abuse rate limit menuntut perlindungan tambahan di level header, session, dan secret management. Artikel ini langsung menjelaskan langkah teknis yang bisa diimplementasikan pada CodeIgniter 4 untuk memastikan token, header, dan secret selalu divalidasi, dan mekanisme rotasi tetap aman.

1. Mengidentifikasi Ancaman Header dan Session

Permintaan API bisa dimanipulasi lewat header palsu atau reuse token setelah catatan session/kookie bocor. Fokus berikut: menolak permintaan tanpa header wajib, memastikan session tidak diekspos, dan menandai abuse rate limit yang tidak valid.

  • CSRF: meski API stateless, header custom seperti X-Auth-Nonce atau X-Request-Sign membantu mendeteksi permintaan terduplikasi.
  • Token leakage: validasi header Authorization serta header cabang (misal X-Forwarded-For) mencegah token reuse dari sumber tidak sah.
  • Abuse rate limit: header wajib bisa menjadi sinyal tambahan ketika rate limit di-bypass (misal header signature berubah tapi token sama).

2. Memanfaatkan Filter dan Validation Rule untuk Header dan Payload

Buat filter khusus yang dijalankan sebelum controller API untuk memeriksa header wajib. Filter ini bisa disusun dalam app/Filters dan diaktifkan lewat Config/Filters.php.

Contoh filter validasi header

namespace Appilters;

use CodeIgniteriltersilterInterface;
use CodeIgniterilters
equestInterface;
use CodeIgniterilters
esponseInterface;

class AuthHeaderFilter implements filterInterface
{
    public function before(requestInterface $request, $arguments = null)
    {
        $auth = $request->getHeaderLine('Authorization');
        $nonce = $request->getHeaderLine('X-Auth-Nonce');

        if (empty($auth) || empty($nonce)) {
            return Services::response()
                ->setStatusCode(400)
                ->setJSON(['error' => 'Header otentikasi tidak lengkap']);
        }

        // Validasi format, misal Bearer token
        if (!preg_match('/^Bearer\s+[A-Za-z0-9-_.]+$/', $auth)) {
            return Services::response()
                ->setStatusCode(401)
                ->setJSON(['error' => 'Authorization header tidak valid']);
        }

        // Simpan nonce untuk pengecekan duplikat, abuse, atau rate limit.
        $request->setUserData('authNonce', $nonce);
    }

    public function after(requestInterface $request, responseInterface $response, $arguments = null)
    {
        // Tidak diperlukan untuk validasi header
    }
}

Filter ini menolak permintaan yang tidak memiliki header yang diperlukan serta memastikan format token lokal. Gabungkan dengan rule validasi payload (misal form validation untuk struktur JSON) untuk mencegah input berbahaya. Terapkan filter melalui routing API dengan grup di Config/Filters.php atau Routes.php agar semua endpoint Auth memerlukannya.

3. Konfigurasi Secret yang Aman dan Warning Rotasi

Secret API sebaiknya tidak disimpan langsung di repository. Gunakan .env dengan app.secret atau masukan rahasia lewat secret vault. Contoh definisi:

app.env = production
app.secret = {SECRET_FROM_VAULT}
app.secret_secondary = {OLD_SECRET}

Di App/Config/App.php, akses secret lewat env('app.secret') dan env('app.secret_secondary'). Struktur ini mendukung rotasi key, karena ada secret primer dan sekunder.

Strategi rotasi secret

  1. Wing fallback: Gunakan secret sekunder untuk memverifikasi token lama selama window rotasi, bukan langsung menolak. Ini mencegah gangguan layanan saat rolling secret.
  2. Audit key usage: Logging tiap verifikasi secret (primer/sekunder) membantu mendeteksi permintaan yang masih memakai token lama setelah rotasi.
  3. Rollout bertahap: Perbarui secret di environment secara paralel: pertama simpan secret baru di app.secret dan pindahkan secret sebelumnya ke app.secret_secondary, lalu reload worker/API.

Contoh helper verifikasi secret:

function verifySecret(string $payload, string $signature): bool
{
    $secrets = [env('app.secret'), env('app.secret_secondary')];

    foreach ($secrets as $secret) {
        if (is_string($secret) && hash_equals(hash_hmac('sha256', $payload, $secret), $signature)) {
            return true;
        }
    }

    return false;
}

Jika verifikasi hanya berhasil dengan secret sekunder, catat di log agar tim keamanan tahu permintaan tersebut masih memanfaatkan key lama. Setelah periode transisi selesai, kosongkan app.secret_secondary dan jalankan audit ulang.

4. Session dan Cookie-safe Handling

Meski API biasanya stateless, session dari client-side tetap bisa berinteraksi lewat cookies. Pastikan:

  • Cookie HttpOnly dan Secure: untuk cookie yang menyimpan csrf token atau session id, set HttpOnly guna mencegah akses JavaScript.
  • SameSite=strict/lax: mencegah CSRF lewat third-party.
  • Regenerate session token: setelah pengguna berhenti atau logout, pastikan session dihapus dan token tidak disimpan kembali di browser.

CodeIgniter 4 menyediakan konfigurasi session di Config/App.php. Pastikan session.cookie_secure dan session.cookie_httponly diaktifkan.

5. Checklist Deploy Aman dan Logging Anomali

Checklist sebelum deploy

  • Pastikan filter header aktif di semua endpoint Auth.
  • Secret primer/sekunder diterapkan lewat environment variable atau vault, bukan hardcode.
  • Rotasi key sudah ditest di staging dengan fallback dan rollback plan.
  • Rate limit enforcement aktif, dan nonce/header abuse diasah untuk mendeteksi permintaan tinggi tanpa header valid.

Logging dan alert

Gunakan logging terstruktur untuk kejadian seperti:

  • Permintaan ditolak karena header tidak lengkap atau format token salah.
  • Verifikasi hanya berhasil dengan secret sekunder (indikasi token lama masih aktif).
  • Abuse rate limit: permintaan dengan nonce duplikat atau origin berbeda.

Integrasikan dengan alert (Opsgenie, PagerDuty) bila thresholds kegagalan otentikasi terlampaui agar tim dapat memeriksa potensi leak atau brute force.

Kesimpulan

Memperkuat Auth API CodeIgniter 4 membutuhkan validasi header/filter, session-safe handling, dan manajemen secret yang terencana termasuk rotasi dengan fallback. Gunakan filter untuk mencegah header incomplete, konfigurasi secret lewat .env atau vault, serta catat aktivitas saat secret lama masih dipakai. Dengan checklist deployment dan logging anomali, Anda bisa menjaga otentikasi API tetap kuat terhadap serangan.