CSRF dalam pengembangan mobile: esensi, jenis serangan dan metode perlindungan

Apa itu serangan CSRF?

CSRF (Cross-Site Request Forgery) adalah serangan di mana penyerang membuat permintaan palsu dan memaksa browser korban untuk mengirimkannya ke server target. Server menjalankan permintaan karena menerima kredensial cookie yang valid dari sesi pengguna saat ini. Serangan mungkin terjadi karena browser secara otomatis menambahkan cookie ke setiap permintaan ke domain target, terlepas dari halaman mana permintaan dikirim. Pengguna mungkin bahkan tidak melihat halaman penyerang — cukup memuat <img>, <form> atau <iframe> tersembunyi dengan URL berbahaya. CSRF tidak mencuri data secara langsung — serangan melakukan tindakan atas nama korban (operasi pengubah status), seperti transfer uang, mengubah kata sandi, atau menghapus akun.

Operasi mana yang paling rentan?

Serangan CSRF hanya ditujukan pada operasi yang mengubah status — permintaan GET dengan efek samping, POST, PUT dan DELETE. Misalnya, permintaan untuk mengubah alamat email di akun pribadi: jika server menerima permintaan tanpa memeriksa asal, penyerang dapat mengganti emailnya sendiri dan memulai reset kata sandi. Serangan ini sangat berbahaya untuk sistem perbankan, panel admin, dan jejaring sosial, di mana satu tindakan memiliki konsekuensi serius. API aplikasi mobile yang menggunakan cookie untuk autentikasi juga rentan terhadap CSRF jika tidak menerapkan pemeriksaan tambahan.

Siapa yang berisiko?

Semua aplikasi web dan API di mana autentikasi didasarkan pada cookie dan server tidak memeriksa asal permintaan, berisiko terkena serangan. Aplikasi mobile yang menggunakan WebView untuk otorisasi melalui formulir web juga rentan: komponen browser secara otomatis mengirim cookie, dan penyerang dapat menyuntikkan permintaan berbahaya melalui pemuatan latar belakang. Menurut HackerOne (2025), sekitar 12% dari semua laporan kerentanan di aplikasi web terkait dengan kurangnya perlindungan CSRF.

Apa yang membuat CSRF berbahaya?

Fitur utama CSRF adalah ketidakterlihatannya bagi korban. Pengguna mungkin bahkan tidak curiga bahwa serangan telah terjadi: permintaan palsu dijalankan di latar belakang, dan antarmuka aplikasi tidak menunjukkan tanda-tanda peretasan. Satu-satunya cara untuk mendeteksi CSRF adalah memantau log server atau perubahan mendadak di akun. Selain itu, CSRF mudah dikombinasikan dengan kerentanan lain, seperti XSS atau pengalihan terbuka, yang melipatgandakan kerusakan.

Bagaimana cara kerja serangan CSRF?

Serangan CSRF terdiri dari tiga kondisi wajib: korban telah terautentikasi di situs target, server menggunakan autentikasi cookie, dan permintaan penyerang diarahkan ke URL tindakan. Penyerang membuat halaman HTML dengan formulir, skrip, atau gambar yang atribut src-nya menunjuk ke URL target. Browser korban memuat halaman ini dan secara otomatis mengirim permintaan ke server bersama dengan cookie sesi saat ini. Server menerima cookie yang valid, tidak memeriksa sumber permintaan, dan menjalankan operasi.

<!-- Contoh serangan CSRF melalui form tersembunyi -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Setelah halaman dimuat, skrip segera mengirim formulir. Browser melampirkan cookie sesi pengguna ke permintaan POST ke bank.example.com. Server bank memeriksa cookie, memastikan pengguna telah terautentikasi, dan melakukan transfer ke akun penyerang. Korban melihat halaman kosong atau sah, dan uang telah didebet.

Peran browser dalam CSRF

Fitur utama protokol HTTP — tidak adanya pemeriksaan sumber bawaan permintaan. Browser menambahkan cookie ke permintaan jika domain permintaan cocok dengan domain cookie. Penyerang tidak perlu mengetahui isi cookie — browser melakukannya secara otomatis. Same-origin policy tidak melindungi dari CSRF karena serangan ditujukan ke server, bukan untuk membaca respons. Mekanisme seperti CORS juga tidak berdaya: permintaan CSRF biasanya tidak memerlukan pembacaan respons untuk menyebabkan kerusakan.

Jenis utama serangan CSRF

Serangan CSRF diklasifikasikan berdasarkan metode pengiriman permintaan berbahaya. Setiap jenis menggunakan elemen HTML yang berbeda untuk mengirim permintaan, tetapi semuanya bergantung pada pengiriman cookie otomatis oleh browser. Pemilihan metode tergantung pada tujuan penyerang: serangan GET-based membutuhkan lebih sedikit kode, POST-based lebih andal dalam melewati beberapa perlindungan, dan XMLHttpRequest-based memungkinkan manipulasi header.

GET-based CSRF

Metode paling sederhana: penyerang menempatkan <img> di halaman dengan URL yang berisi parameter permintaan. Browser memuat gambar dan mengirim permintaan GET ke server. Misalnya, <img src="https://api.example.com/delete?postId=123" /> menghapus entri jika server memproses DELETE melalui GET. Meskipun bahayanya jelas, beberapa API masih menggunakan GET untuk operasi penghapusan atau pembaruan.

POST-based CSRF

Jika server hanya menerima permintaan POST, penyerang membuat formulir tersembunyi dengan metode POST dan secara otomatis mengirimkannya melalui JavaScript. Formulir tidak ditampilkan di layar (semua <input> memiliki type="hidden"), dan autofocus + .submit() bekerja tanpa klik pengguna. Serangan POST-based tidak berfungsi jika server memeriksa header Content-Type, tetapi sebagian besar API menerima application/x-www-form-urlencoded standar.

XHR-based CSRF (dengan CORS)

XMLHttpRequest atau Fetch API memungkinkan pengiriman permintaan dengan header arbitrer. Jika server mengonfigurasi CORS terlalu luas (Access-Control-Allow-Origin: *), penyerang dapat mengirim permintaan apa pun dan membaca respons. Namun, untuk serangan CSRF, membaca respons tidak diperlukan — cukup menjalankan tindakan. Browser modern mengirim permintaan preflight OPTIONS sebelum permintaan non-standar, yang dapat memblokir XHR-based CSRF jika server dikonfigurasi dengan benar.

CSRF di aplikasi mobile

Aplikasi mobile lebih jarang rentan terhadap CSRF dibandingkan situs web, karena aplikasi native jarang menggunakan autentikasi cookie. Sebagai gantinya, API mobile lebih sering menerapkan token di header Authorization (token Bearer, JWT). Namun ada skenario di mana serangan CSRF mungkin terjadi: WebView dengan login web, aplikasi hybrid, dan API dengan sesi berbasis cookie. Menurut TechCrunch (2025), sekitar 18% API publik aplikasi mobile masih mendukung cookie sesi.

CSRF melalui WebView

Banyak aplikasi membuka halaman web di WebView — otorisasi melalui OAuth, formulir pembayaran, melihat konten. WebView adalah browser lengkap di dalam aplikasi yang menyimpan cookie sesi. Jika penyerang menemukan cara untuk memuat URL-nya di WebView (melalui pengalihan terbuka atau Deep Link), ia dapat melakukan serangan CSRF persis seperti di browser biasa. Perlindungan — menggunakan Chrome Custom Tabs atau SFSafariViewController sebagai pengganti WebView untuk operasi kritis.

CSRF di API dengan autentikasi JWT

Token JWT biasanya disimpan di localStorage atau di memori aplikasi dan tidak dikirim secara otomatis — pengembang secara eksplisit menambahkan header Authorization ke setiap permintaan. Ini membuat serangan CSRF klasik menjadi tidak mungkin. Namun jika aplikasi menyimpan JWT di cookie (jarang tetapi terjadi), risikonya kembali. Perlindungan tambahan — mengikat JWT ke asal permintaan tertentu melalui klaim azp atau aud, yang mencegah penggunaan token di domain lain.

// Contoh validasi token CSRF sisi server di Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Pembuatan token CSRF saat login
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Metode perlindungan terhadap CSRF

Perlindungan modern terhadap CSRF didasarkan pada tiga tingkat: token CSRF sisi server, atribut SameSite untuk cookie, dan verifikasi header Origin. Kombinasi metode ini memberikan perlindungan terhadap 99% serangan CSRF tanpa dampak signifikan pada UX. Pemilihan pendekatan spesifik tergantung pada arsitektur aplikasi: situs web cukup menggunakan SameSite=Lax, API aplikasi mobile memerlukan token di header.

Token CSRF (sinkronisasi)

Metode standar: server menghasilkan token unik, mengikatnya ke sesi pengguna, dan mengirimkannya ke klien. Klien menyertakan token dalam setiap permintaan yang mengubah status (di bidang tersembunyi formulir atau header X-CSRF-Token). Server membandingkan token yang diterima dengan yang disimpan di sesi. Token harus aman secara kriptografis, acak, minimal 32 byte, dan berubah di setiap sesi atau operasi. Masa berlaku token — tidak lebih dari beberapa jam.

SameSite Cookie

Atribut SameSite untuk cookie membatasi pengiriman cookie pada permintaan lintas domain. Nilai Lax mengizinkan pengiriman cookie hanya untuk permintaan GET navigasi tingkat atas — ini cukup untuk sebagian besar situs. Strict memblokir cookie untuk semua permintaan lintas domain, termasuk navigasi: pengguna harus login kembali saat berpindah dari situs lain. Menurut Chrome Platform Status (2026), SameSite=Lax diaktifkan secara default di semua browser modern, yang telah mengurangi jumlah serangan CSRF sebesar 67%.

Verifikasi Origin dan Referer

Server dapat memeriksa header Origin atau Referer dari permintaan masuk. Jika permintaan berasal dari domain lain — akan diblokir. Origin lebih andal daripada Referer karena selalu ada di permintaan POST dan tidak dinonaktifkan oleh kebijakan browser. Implementasi: daftar putih origin yang diizinkan, perbandingan dengan nilai header saat ini. Metode ini efektif tetapi rumit dengan aplikasi mobile di mana header Origin mungkin tidak ada atau dipalsukan.

// Contoh validasi token CSRF di Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Metode yang tidak memerlukan penyimpanan token di server: server menyetel cookie dengan nilai acak, klien membaca nilai dari cookie dan mengirimkannya kembali di header atau badan permintaan. Server membandingkan kedua nilai. Jika penyerang tidak dapat membaca cookie (Same-origin policy), ia tidak akan dapat memalsukan token. Metode ini lebih mudah diimplementasikan daripada sinkronisasi, tetapi memerlukan HTTPS untuk melindungi cookie dari penyadapan.

• Token CSRF — standar emas: andal, teruji waktu, didukung oleh semua framework
• SameSite=Lax — perlindungan minimal untuk aplikasi web: gratis, otomatis, tidak memerlukan kode
• Verifikasi Origin — tingkat tambahan: memblokir serangan sebelum verifikasi token
• Double Submit — untuk REST API tanpa sesi sisi server: efektif di HTTPS
• Header khusus — X-Requested-With: XMLHttpRequest memblokir formulir CSRF sederhana

Perbedaan antara CSRF dan XSS

CSRF dan XSS adalah jenis serangan yang berbeda yang sering tertukar. CSRF mengeksploitasi kepercayaan server terhadap browser pengguna: server menjalankan perintah penyerang karena permintaan datang dengan cookie yang valid. XSS mengeksploitasi kepercayaan browser terhadap konten server: browser menjalankan skrip yang disuntikkan penyerang ke halaman. CSRF tidak memerlukan penyuntikan kode di situs target — cukup mengirim permintaan dari domain lain. XSS sebaliknya, memerlukan menemukan cara untuk menyuntikkan JavaScript sendiri ke kode HTML halaman. Selain itu, XSS dapat melewati perlindungan CSRF: skrip yang disuntikkan membaca token CSRF dari halaman dan mengirimkannya bersama dengan permintaan.

Memahami perbedaan antara CSRF dan XSS sangat penting untuk membangun perlindungan berlapis. Token CSRF tidak melindungi dari XSS, dan CSP (Content Security Policy) tidak melindungi dari CSRF. Hanya kombinasi metode yang memastikan keamanan aplikasi dari kedua jenis serangan. Di aplikasi mobile dengan WebView, risiko berlipat ganda, oleh karena itu pengembang disarankan untuk menerapkan setidaknya token CSRF untuk permintaan API dan Content Security Policy untuk konten web.