Client-Side Policy Enforcement: Membangun Otorisasi Granular di Frontend dengan Policy-as-Code (PaC)

Ketika kita berbicara tentang keamanan aplikasi web, otorisasi—siapa yang boleh melakukan apa—adalah fondasi yang tak terpisahkan. Umumnya, kita mengandalkan backend untuk memeriksa setiap permintaan, memastikan pengguna memiliki izin yang sesuai. Namun, bagaimana jika kita bisa membawa sebagian dari kecerdasan otorisasi ini ke frontend, tidak hanya untuk UX yang lebih baik, tetapi juga untuk membangun aplikasi yang lebih tangguh dan konsisten?

Artikel ini akan membahas konsep Client-Side Policy Enforcement menggunakan pendekatan Policy-as-Code (PaC). Kita akan melihat mengapa ini penting, keterbatasan pendekatan tradisional, dan bagaimana kita bisa mengimplementasikannya untuk otorisasi granular di aplikasi web modern Anda.

1. Pendahuluan: Lebih dari Sekadar Sembunyikan Tombol

Pernahkah Anda melihat tombol atau menu yang seharusnya hanya muncul untuk admin, tapi tiba-tiba muncul di UI pengguna biasa? Atau mungkin, Anda mengklik sebuah fitur dan harus menunggu respons server hanya untuk diberitahu bahwa Anda tidak memiliki izin? Ini adalah masalah umum dalam otorisasi di frontend.

Secara fundamental, otorisasi adalah tanggung jawab backend. Frontend tidak pernah boleh menjadi satu-satunya sumber kebenaran untuk izin. Backend harus selalu memvalidasi setiap permintaan. Namun, mengabaikan otorisasi di frontend sepenuhnya dapat menyebabkan:

1. Pengalaman Pengguna yang Buruk (Bad UX): Latensi yang tidak perlu karena setiap interaksi UI harus menunggu validasi backend.
2. Kebocoran Informasi Terselubung: Pengguna bisa melihat elemen UI yang seharusnya tidak terlihat, bahkan jika mereka tidak bisa berinteraksi dengannya. Ini bisa menimbulkan kebingungan atau bahkan menjadi petunjuk bagi penyerang.
3. Duplikasi Logika: Developer frontend sering kali mencoba mereplikasi logika otorisasi backend secara ad-hoc, yang sulit dikelola dan rawan inkonsistensi.

Di sinilah Client-Side Policy Enforcement dengan Policy-as-Code (PaC) datang sebagai solusi. Ini bukan pengganti otorisasi backend, melainkan lapisan pertahanan dan user experience tambahan yang kuat.

2. Mengapa Otorisasi di Frontend Penting (dan Batasannya)

Tujuan utama otorisasi di frontend adalah:

• Responsivitas UI: Pengguna langsung mendapatkan feedback visual tentang apa yang bisa dan tidak bisa mereka lakukan, tanpa menunggu respons server.
• Kejelasan Fungsionalitas: Menyembunyikan atau menonaktifkan elemen UI yang tidak relevan dapat mengurangi kebingungan pengguna.
• Mengurangi Beban Backend: Meskipun tidak membebaskan backend dari validasi, mengurangi permintaan validasi yang tidak perlu untuk setiap perubahan UI dapat menghemat sumber daya.

⚠️ Peringatan Penting: Otorisasi di frontend hanya untuk UX dan visualisasi. Backend harus selalu melakukan validasi otorisasi yang ketat. Anggap saja frontend sebagai “peringatan dini” atau “panduan”, bukan “penegak hukum” utama. Pengguna yang cerdik atau berniat jahat dapat melewati kontrol frontend.

3. Keterbatasan Otorisasi Tradisional di Frontend

Pendekatan umum untuk otorisasi di frontend sering kali melibatkan:

• Pengecekan Peran Sederhana: if (user.role === 'admin') { showAdminButton() }. Ini cocok untuk Role-Based Access Control (RBAC) dasar, tetapi sulit untuk aturan yang lebih kompleks.
• Logika Kondisional Hardcoded: Aturan otorisasi ditulis langsung dalam kode komponen UI. Seiring bertambahnya kompleksitas aplikasi (misalnya, Attribute-Based Access Control / ABAC), kode menjadi berantakan, sulit diuji, dan sulit disinkronkan dengan backend.
• Fetching Izin dari Backend: Setiap kali ada kebutuhan untuk memeriksa izin granular, frontend membuat permintaan API ke backend. Ini memperkenalkan latensi dan kompleksitas caching.

Masalah utama dari pendekatan ini adalah skalabilitas dan konsistensi. Bagaimana jika ada 100 aturan otorisasi yang berbeda, bergantung pada atribut pengguna, atribut resource, dan kondisi lingkungan? Kode frontend Anda akan menjadi mimpi buruk.

4. Memperkenalkan Policy-as-Code (PaC) untuk Frontend

Apa itu Policy-as-Code (PaC)?

Policy-as-Code (PaC) adalah praktik mendefinisikan, mengelola, dan menerapkan kebijakan (rules) sebagai kode. Sama seperti Infrastructure-as-Code (IaC) yang mengelola infrastruktur, PaC mengelola kebijakan. Kebijakan ini disimpan dalam sistem kontrol versi (Git), dapat diuji, dan diterapkan secara otomatis.

Contoh kebijakan bisa berupa:

• “Hanya pengguna dengan peran editor yang dapat mengedit artikel yang mereka buat.”
• “Pengguna di departemen marketing dapat melihat laporan campaign_performance.”

Manfaat PaC di Frontend:

Dengan mengadopsi PaC di frontend, kita mendapatkan keuntungan signifikan:

✅ Konsistensi: Kebijakan yang sama dapat digunakan dan diterapkan di backend, API Gateway, dan frontend, memastikan semua lapisan aplikasi memiliki pemahaman yang sama tentang aturan otorisasi. ✅ Auditabilitas: Karena kebijakan adalah kode, setiap perubahan dapat dilacak di Git, memberikan riwayat audit yang jelas. ✅ Testabilitas: Kebijakan dapat diuji secara terpisah dan otomatis, memastikan mereka bekerja seperti yang diharapkan dan tidak ada regresi. ✅ Desentralisasi Kebijakan: Logika otorisasi terpisah dari logika bisnis UI, memungkinkan tim keamanan atau policy engineers untuk mengelola aturan secara terpusat. ✅ Developer Experience (DX): Frontend developer dapat dengan mudah mengintegrasikan dan menggunakan kebijakan tanpa harus memahami detail implementasi otorisasi yang kompleks.

5. Strategi Implementasi PaC di Frontend

Ada beberapa cara untuk menerapkan PaC di frontend. Kita akan fokus pada pendekatan yang paling kuat: Pola Kebijakan Terkompilasi.

🎯 Pola Kebijakan Terkompilasi (Compiled Policies)

Dalam pola ini, kebijakan otorisasi ditulis dalam bahasa khusus (misalnya, Rego dari Open Policy Agent, atau Cedar dari AWS) dan kemudian dikompilasi menjadi format yang dapat dieksekusi di browser, seperti JavaScript atau WebAssembly.

Alur Kerja Umum:

1. Definisi Kebijakan: Tim keamanan/backend mendefinisikan kebijakan otorisasi granular dalam bahasa PaC (misal: Rego).
2. Kompilasi: Kebijakan tersebut dikompilasi menjadi bundle JavaScript atau WebAssembly yang ringkas.
3. Distribusi: Bundle kebijakan ini didistribusikan bersama aset frontend Anda.
4. Evaluasi di Frontend: Aplikasi frontend memuat bundle kebijakan dan mengevaluasinya secara lokal di browser, berdasarkan data konteks (pengguna, resource, lingkungan).

Contoh Konkret (dengan Pseudocode & Konsep Rego)

Mari kita bayangkan kita ingin mengontrol akses ke tombol “Edit Post” di blog kita. Aturannya adalah:

• Admin bisa mengedit post apa pun.
• Penulis (author) hanya bisa mengedit post mereka sendiri.

1. Definisi Kebijakan (Konsep Rego):

# policy.rego
package blog.post.edit

default allow = false

allow {
    input.user.role == "admin"
}

allow {
    input.user.role == "author"
    input.user.id == input.post.authorId
}

Dalam contoh ini:

• input adalah data konteks yang akan kita berikan ke kebijakan (siapa user-nya, apa post-nya).
• allow akan menjadi true jika salah satu kondisi terpenuhi.

2. Kompilasi & Integrasi ke Frontend:

Open Policy Agent (OPA) memiliki tool yang dapat mengkompilasi kebijakan Rego menjadi WebAssembly. Setelah dikompilasi, Anda akan mendapatkan sebuah .wasm file dan mungkin glue code JavaScript untuk memuat dan berinteraksi dengannya.

// policy-evaluator.js (simplified conceptual example)
import { loadPolicy } from './policy.wasm'; // Asumsi ada loader Wasm

let policyInstance;

async function initPolicy() {
    policyInstance = await loadPolicy();
}

/**
 * Mengevaluasi kebijakan otorisasi.
 * @param {object} inputData - Data konteks (user, post, dll.)
 * @returns {boolean} True jika diizinkan, false jika tidak.
 */
async function checkPermission(inputData) {
    if (!policyInstance) {
        await initPolicy();
    }
    const result = policyInstance.evaluate(inputData);
    // Asumsi hasil evaluasi adalah { "allow": true/false }
    return result && result.length > 0 && result[0].result.allow === true;
}

export { checkPermission };

3. Penggunaan di Komponen UI (React/Vue/Angular):

Sekarang, di komponen React Anda, Anda bisa menggunakannya seperti ini:

// PostItem.jsx (Contoh dengan React)
import React, { useState, useEffect } from 'react';
import { checkPermission } from './policy-evaluator'; // Sesuaikan path

function PostItem({ post, currentUser }) {
    const [canEdit, setCanEdit] = useState(false);

    useEffect(() => {
        async function evaluateEditPermission() {
            const inputData = {
                user: {