Vulnerability Assessment dan Penetration Testing, Cara Temukan Celah Sebelum Diserang

Banyak perusahaan merasa aset digitalnya aman selama website masih bisa diakses, portal pelanggan berjalan normal, dan tidak ada komplain dari user. Masalahnya, penyerang tidak menilai aplikasi publik dari tampilannya. Mereka menilai dari celah yang bisa dipindai, diuji, dan dieksploitasi.

Website, API, form login, dashboard partner, subdomain lama, sampai staging environment yang lupa ditutup bisa menjadi bagian dari attack surface perusahaan. Satu endpoint kecil yang tidak diuji bisa membuka jalan menuju data pelanggan, akun internal, atau sistem yang lebih kritikal.

Inilah inti dari public-facing application risk, risiko yang muncul ketika aset digital yang terbuka ke internet tidak dipetakan, tidak diuji berkala, dan tidak memiliki proses perbaikan celah yang disiplin.

Dalam praktiknya, serangan siber tidak selalu dimulai dari sistem yang paling penting. Sering kali, penyerang masuk dari aset yang dianggap kecil, lama, atau “cuma website biasa”. Padahal selama aset itu bisa diakses dari internet, ia tetap bisa menjadi pintu masuk.

 

Mengapa Aset Publik Selalu Menjadi Permukaan Serangan?

Aplikasi publik punya satu karakter yang membuatnya menarik bagi penyerang, ia terbuka.

Berbeda dengan sistem internal yang hanya bisa diakses dari jaringan tertentu, aplikasi publik dapat dijangkau dari internet. Penyerang tidak perlu berada di kantor perusahaan, tidak perlu mengenal orang dalam, dan tidak perlu punya akses fisik.

Cukup mencari permukaan serangan yang tersedia.

Website company profile, portal pelanggan, aplikasi mobile backend, sistem registrasi, landing page campaign, dashboard vendor, e-commerce, API publik, hingga subdomain lama yang terlupakan bisa menjadi titik awal serangan.

 

Penyerang Mencari Celah Termudah, Bukan Sistem Paling Penting

Salah satu kesalahan umum perusahaan adalah mengira penyerang hanya akan menyerang sistem utama. Padahal, penyerang biasanya mencari jalur yang paling mudah.

Jika aplikasi utama sulit ditembus, mereka bisa mencoba subdomain lama. Jika login portal cukup kuat, mereka bisa mencari API yang tidak terdokumentasi. Jika server utama terlindungi, mereka bisa mencari file konfigurasi yang terbuka, plugin usang, endpoint tidak terlindungi, atau form input yang rentan.

Dalam keamanan aplikasi web, aset kecil yang terlupakan sering lebih berbahaya daripada sistem besar yang sudah dijaga ketat.

Itulah sebabnya keamanan website perusahaan tidak bisa hanya bergantung pada asumsi bahwa “selama sistem berjalan, berarti aman”.

 

Baca juga : Apa Itu Ethical Hacker? Peran Hacker Baik untuk Penetration Testing

 

Aplikasi Publik Berubah Lebih Cepat daripada Pengujiannya

Aplikasi publik jarang benar-benar statis.

Ada update fitur. Ada perubahan plugin. Ada integrasi baru. Ada form tambahan. Ada script pihak ketiga. Ada API baru untuk mendukung aplikasi mobile. Ada landing page campaign yang dibuat cepat karena kebutuhan bisnis.

Setiap perubahan bisa menambah celah baru.

Masalahnya, proses security testing sering tidak mengikuti kecepatan perubahan tersebut. Tim development selesai deploy. Bisnis senang karena fitur berjalan. Namun tidak selalu ada vulnerability assessment atau penetration testing yang memadai setelah perubahan dilakukan.

Di sinilah risiko aplikasi publik mulai menumpuk diam-diam.

 

Public-Facing Application Risk

Secara sederhana, public-facing application risk adalah risiko keamanan dari aset digital yang dapat diakses publik melalui internet. Bentuknya bisa berupa website, portal, API, dashboard, aplikasi transaksi, aplikasi mobile backend, atau sistem lain yang terbuka bagi pengguna eksternal.

Risikonya bukan karena aset tersebut publik. Banyak aplikasi memang harus publik agar bisnis berjalan.

Risikonya muncul ketika perusahaan tidak tahu seluruh aset publik yang dimiliki, tidak memahami mana yang paling kritikal, tidak menguji celah secara berkala, dan tidak memiliki proses remediation yang jelas saat vulnerability ditemukan.

Contoh aset public-facing antara lain:

• website perusahaan;
• portal pelanggan;
• aplikasi e-commerce;
• form login;
• API publik;
• dashboard vendor atau partner;
• aplikasi mobile backend;
• sistem registrasi online;
• landing page campaign;
• subdomain lama yang masih aktif;
• staging environment yang terbuka;
• webmail atau admin panel yang bisa diakses dari internet.

Tidak semua aset publik otomatis berbahaya. Yang berbahaya adalah ketika aset tersebut tidak dipetakan, tidak diuji, tidak dimonitor, dan tidak memiliki owner yang jelas.

 

Baca juga : 7 Alat Penetration Testing dan Rekomendasi Sertifikasi Terbaik

 

Celah yang Sering Luput di Website, API, dan Subdomain Lama

Public-facing application risk sering tidak terlihat karena dari luar sistem tampak normal. Website bisa dibuka. Form bisa digunakan. Login berjalan. Dashboard tampil.

Namun keamanan tidak bisa dinilai hanya dari apakah sistem terlihat berfungsi.

• Celah Input dan Validasi Data

Banyak serangan aplikasi web berawal dari input yang tidak divalidasi dengan baik.

Form pencarian, form login, kolom komentar, upload file, parameter URL, atau request API bisa menjadi jalur eksploitasi jika tidak dikontrol. Risiko seperti injection, cross-site scripting, file upload abuse, dan manipulasi parameter sering muncul dari titik yang terlihat sederhana.

Bagi user biasa, form hanya tempat mengisi data. Bagi penyerang, form adalah pintu untuk menguji bagaimana sistem merespons input yang tidak wajar.

• Authentication dan Session Management yang Lemah

Login adalah salah satu area paling sensitif dalam web application security.

Masalah bisa muncul dari password policy yang lemah, tidak adanya multi-factor authentication, session token yang tidak aman, reset password yang mudah dimanipulasi, atau mekanisme logout yang tidak benar-benar mengakhiri sesi.

Jika authentication lemah, penyerang tidak selalu perlu membobol server. Cukup mengambil alih akun.

Untuk aplikasi yang menyimpan data pelanggan, data transaksi, atau informasi internal, risiko ini bisa berdampak serius.

• API yang Tidak Terkontrol

Banyak perusahaan kini menggunakan API untuk menghubungkan website, aplikasi mobile, CRM, payment gateway, platform marketing, hingga sistem internal.

API sering menjadi titik rawan karena tidak selalu terlihat oleh user biasa, tetapi sangat menarik bagi penyerang. API yang tidak memiliki authentication kuat, rate limiting, validasi input, atau kontrol akses yang tepat dapat dieksploitasi untuk mengambil data dalam jumlah besar.

Masalahnya, API sering berkembang cepat mengikuti kebutuhan produk. Jika dokumentasi dan pengujian tidak rapi, endpoint lama bisa tetap aktif tanpa pengawasan.

Dan ini yang sering terjadi: website terlihat aman, tetapi API di belakangnya justru membuka jalur yang lebih langsung ke data.

• Komponen Usang dan Dependency Rentan

Website modern jarang dibangun dari nol. Ada framework, library, plugin, CMS, tema, modul pembayaran, analytics script, hingga komponen pihak ketiga.

Setiap komponen punya risiko.

Jika plugin tidak diperbarui, library memiliki vulnerability, atau dependency lama tetap digunakan, aplikasi bisa menjadi sasaran. Ini terutama sering terjadi pada website yang awalnya dibuat untuk kebutuhan marketing, lalu dibiarkan berjalan bertahun-tahun tanpa security review rutin.

Tampilannya mungkin masih bagus. Tetapi di belakang layar, komponennya bisa sudah rapuh.

• Subdomain dan Aset Lama yang Terlupakan

Salah satu sumber risiko yang paling sering luput adalah aset lama.

Subdomain untuk campaign lama. Portal uji coba. Aplikasi demo. Staging environment yang masih terbuka. Admin panel yang tidak lagi digunakan. Server lama yang tidak masuk monitoring.

Aset seperti ini sering tidak masuk prioritas karena dianggap tidak aktif. Padahal, selama masih bisa diakses dari internet, ia tetap menjadi bagian dari attack surface perusahaan.

Dalam banyak kasus, masalah bukan karena perusahaan tidak punya sistem keamanan. Masalahnya adalah perusahaan tidak tahu semua aset publik yang mereka miliki.

 

Dampak Bisnis Saat Celah Aplikasi Publik Dibiarkan Terbuka

Celah keamanan website bukan hanya masalah teknis. Dampaknya bisa masuk ke area bisnis, hukum, reputasi, operasional, dan kepercayaan pelanggan.

• Gangguan Layanan

Jika aplikasi publik diserang, layanan bisa terganggu. Website tidak bisa diakses. Portal pelanggan error. Sistem transaksi lambat. API tidak merespons.

Untuk perusahaan yang bergantung pada kanal digital, downtime bukan sekadar gangguan IT. Itu bisa berarti kehilangan lead, transaksi, kepercayaan pelanggan, dan peluang bisnis.

• Kebocoran Data

Jika aplikasi publik menyimpan atau mengakses data pelanggan, data akun, data transaksi, atau dokumen internal, celah keamanan dapat membuka jalan menuju kebocoran data.

Risikonya makin besar jika aplikasi terhubung ke sistem lain. Satu celah kecil di aplikasi publik bisa menjadi pintu untuk bergerak lebih jauh ke lingkungan internal.

• Kerusakan Reputasi

Publik sering melihat website sebagai wajah perusahaan. Jika website diretas, dirusak, atau digunakan untuk menyebarkan konten berbahaya, reputasi perusahaan bisa ikut turun.

Yang lebih berat, pelanggan biasanya tidak peduli apakah celahnya berasal dari plugin, API, konfigurasi server, atau kesalahan coding. Di mata mereka, perusahaan gagal menjaga sistem digitalnya.

• Biaya Perbaikan yang Lebih Mahal

Menutup celah setelah insiden biasanya jauh lebih mahal dibanding mengujinya sejak awal.

Setelah insiden, perusahaan harus melakukan investigasi, pemulihan sistem, komunikasi internal, komunikasi pelanggan, review legal, perbaikan teknis, dan kadang melibatkan pihak eksternal dalam tekanan waktu.

Sementara itu, serangan sudah terjadi.

 

Baca juga : Awas! Karyawan Jual Akses Perusahaan di Dark Web, Jutaan Data Rahasia Melayang

 

Kesalahan yang Membuat Website Publik Tetap Rentan

Banyak perusahaan sebenarnya sadar bahwa website perlu aman. Namun praktiknya sering belum cukup disiplin.

• Menganggap Website Company Profile Tidak Berisiko

Karena website company profile tidak selalu menyimpan data transaksi, sebagian perusahaan menganggap risikonya rendah.

Ini cara berpikir yang terlalu nyaman.

Website company profile tetap bisa menjadi target. Ia bisa digunakan untuk defacement, phishing, penyebaran malware, pencurian kredensial admin, atau pivot ke sistem lain jika konfigurasinya buruk.

Aset publik tetap harus dikelola sebagai aset keamanan.

• Security Testing Hanya Dilakukan Sekali

Vulnerability assessment atau penetration testing sering dilakukan saat awal peluncuran aplikasi. Setelah itu, tidak pernah diulang.

Padahal, aplikasi berubah. Infrastruktur berubah. Komponen berubah. Teknik serangan juga berubah.

Security testing yang dilakukan setahun lalu tidak otomatis menjamin aplikasi tetap aman hari ini.

• Tidak Ada Ownership yang Jelas

Kadang website dikelola oleh vendor, kontennya oleh marketing, infrastrukturnya oleh IT, dan keamanannya dianggap tanggung jawab “nanti kalau ada masalah”.

Ini berbahaya.

Setiap aplikasi publik harus punya owner yang jelas. Siapa yang bertanggung jawab atas update, akses admin, patching, backup, monitoring, dan tindak lanjut temuan keamanan?

Tanpa ownership, celah mudah dibiarkan karena semua orang mengira orang lain yang mengurusnya.

• Temuan Security Tidak Ditindaklanjuti

Melakukan vulnerability assessment saja belum cukup. Yang lebih penting adalah bagaimana temuan ditindaklanjuti.

Dalam banyak organisasi, masalah VAPT bukan hanya menemukan celah. Masalah yang lebih sering terjadi adalah temuan tidak punya owner, tidak punya target penyelesaian, dan tidak pernah diuji ulang setelah diperbaiki.

Jika hasil assessment hanya menjadi file PDF di folder bersama, risikonya tetap ada. Temuan harus diprioritaskan, diberi owner, dijadwalkan perbaikannya, diuji ulang, dan ditutup secara formal.

Security bukan kegiatan mencari masalah. Security adalah proses memastikan masalah benar-benar diselesaikan.

 

Tips Aplikasi Publik Tidak Jadi Pintu Masuk Serangan

Perusahaan tidak harus menunggu insiden untuk mulai memperbaiki keamanan aplikasi publik. Ada beberapa tips yang bisa dibangun lebih awal.

1. Public Asset Inventory

Langkah pertama adalah mengetahui semua aset digital yang terbuka ke internet.

Ini mencakup domain, subdomain, aplikasi web, API, server, staging environment, admin panel, dan portal pihak ketiga yang terhubung dengan perusahaan.

Tanpa inventaris aset, perusahaan hanya mengamankan sesuatu yang terlihat, bukan seluruh permukaan serangan.

2. Risk-Based Vulnerability Assessment

Tidak semua celah memiliki tingkat risiko yang sama. Karena itu, vulnerability assessment perlu dilakukan dengan pendekatan berbasis risiko.

Aplikasi yang menyimpan data pelanggan, terhubung ke sistem internal, memiliki login user, atau mendukung transaksi bisnis harus mendapat prioritas lebih tinggi.

Tujuannya bukan hanya menemukan vulnerability, tetapi memahami celah mana yang paling berbahaya bagi bisnis.

3. Penetration Testing untuk Aplikasi Kritis

Untuk aplikasi publik yang kritikal, vulnerability scanning saja tidak cukup. Perusahaan perlu melakukan penetration testing untuk melihat bagaimana celah dapat dieksploitasi dalam skenario nyata.

Penetration testing membantu perusahaan memahami dampak dari celah yang ditemukan. Apakah celah itu hanya informasi teknis, atau bisa digunakan untuk mengambil alih akun, mengakses data, memanipulasi transaksi, atau masuk ke sistem lain?

4. Remediation dan Retesting

Temuan keamanan harus ditindaklanjuti dengan proses remediation yang jelas.

Setiap temuan perlu memiliki prioritas, owner, target waktu perbaikan, dan status penyelesaian. Setelah diperbaiki, perlu dilakukan retesting untuk memastikan celah benar-benar tertutup.

Tanpa retesting, perusahaan hanya berharap perbaikan berhasil. Dan berharap bukan kontrol keamanan.

5. Monitoring dan Review Berkala

Keamanan aplikasi publik bukan pekerjaan sekali selesai.

Perusahaan perlu melakukan monitoring, review konfigurasi, patch management, access review, log review, serta pengujian berkala. Setiap perubahan besar pada aplikasi juga sebaiknya diikuti dengan security review.

Aplikasi publik yang terus berubah membutuhkan kontrol yang terus berjalan.

 

Baca juga : Skill IT yang Paling Dicari Tahun 2026 untuk Menjadi Web3 Developer

 

Kapan VAPT Perlu Dilakukan, Bukan Ditunda?

Pertanyaan yang sering muncul bukan hanya apakah perusahaan perlu VAPT, tetapi kapan waktu yang tepat melakukannya.

Jawaban paling aman: sebelum ada insiden.

Namun secara praktis, Vulnerability Assessment & Penetration Testing sangat disarankan ketika perusahaan:

• meluncurkan website atau aplikasi baru;
• melakukan perubahan besar pada aplikasi;
• menambahkan fitur login, pembayaran, upload file, atau integrasi API;
• menyimpan atau memproses data pelanggan;
• menghubungkan aplikasi publik ke sistem internal;
• menggunakan vendor baru untuk pengembangan aplikasi;
• menemukan aktivitas mencurigakan;
• ingin memenuhi kebutuhan audit atau compliance;
• belum pernah menguji aplikasi publik dalam 6–12 bulan terakhir.

Frekuensi ideal bergantung pada tingkat risiko aplikasi. Semakin kritikal aplikasinya, semakin sering pengujian perlu dilakukan.

 

Pertanyaan Kritis Sebelum Menganggap Website Sudah Aman

Jika perusahaan memiliki aplikasi yang bisa diakses publik, jangan mulai dari asumsi bahwa semuanya aman. Mulailah dari pertanyaan sederhana:

• Aset publik apa saja yang kita miliki?
• Apakah semua subdomain dan API sudah terinventarisasi?
• Aplikasi mana yang menyimpan data sensitif?
• Kapan terakhir dilakukan vulnerability assessment?
• Apakah aplikasi kritikal sudah pernah menjalani penetration testing?
• Apakah temuan security sebelumnya sudah diperbaiki?
• Apakah ada retesting?
• Siapa owner setiap aplikasi publik?
• Apakah perubahan aplikasi selalu melalui security review?

Jika sebagian besar jawabannya belum jelas, maka risiko aplikasi publik belum benar-benar dikelola.

 

Kesimpulan

Website, portal, API, dan aplikasi publik bukan hanya aset digital untuk mendukung bisnis. Semuanya juga bagian dari permukaan serangan yang dapat dimanfaatkan pihak luar.

Public-facing application risk menjadi penting karena celah kecil pada aplikasi yang terbuka ke internet bisa berkembang menjadi insiden besar. Dampaknya tidak berhenti pada tim IT. Ia bisa menyentuh data pelanggan, reputasi, operasional, compliance, dan kepercayaan bisnis.

Perusahaan tidak perlu menunggu serangan untuk bertindak. Mulailah dengan memetakan aset publik, menilai risiko, melakukan vulnerability assessment, menjalankan penetration testing untuk aplikasi kritikal, memperbaiki temuan, dan melakukan retesting secara disiplin.

Aplikasi publik yang aman bukan yang tidak pernah berubah. Aplikasi publik yang aman adalah yang diuji, dipantau, dan diperbaiki secara berkala.

Uji Aplikasi Publik Sebelum Celahnya Ditemukan Pihak Lain

Website, portal, dan API yang terbuka ke internet perlu diuji bukan hanya saat pertama kali diluncurkan, tetapi juga ketika ada perubahan fitur, integrasi baru, atau peningkatan risiko bisnis. Celah yang tidak terlihat oleh tim internal bisa saja menjadi jalur paling mudah bagi penyerang.

Melalui pendekatan Vulnerability Assessment & Penetration Testing, perusahaan dapat memetakan celah, memahami dampaknya, menentukan prioritas perbaikan, dan memastikan vulnerability yang sudah diperbaiki benar-benar tertutup melalui retesting.

PROXSIS IT dapat membantu organisasi melakukan pengujian keamanan aplikasi publik secara lebih terarah, sehingga website, portal, dan API tidak hanya berjalan normal, tetapi juga lebih siap menghadapi risiko serangan.

 

 

FAQ

1. Apa itu public-facing application risk?
   Public-facing application risk adalah risiko keamanan dari website, portal, API, atau aplikasi yang dapat diakses publik melalui internet.
2. Mengapa aplikasi publik perlu diuji berkala?
   Karena website, API, plugin, konfigurasi, dan integrasi dapat berubah. Setiap perubahan bisa membuka celah baru yang belum terdeteksi.
3. Apa bedanya vulnerability assessment dan penetration testing?
   Vulnerability assessment menemukan dan menilai celah. Penetration testing menguji apakah celah tersebut dapat dieksploitasi dalam skenario serangan nyata.
4. Kapan perusahaan perlu melakukan VAPT?
   VAPT perlu dilakukan saat aplikasi baru diluncurkan, ada perubahan besar, aplikasi memproses data sensitif, terhubung ke sistem internal, atau belum pernah diuji dalam 6–12 bulan terakhir.
5. Apakah website company profile perlu penetration testing?
   Ya, terutama jika memiliki login admin, plugin, form input, subdomain, integrasi pihak ketiga, atau berada pada infrastruktur yang terhubung dengan sistem lain.
6. Apa yang harus dilakukan setelah vulnerability ditemukan?
   Temuan perlu diprioritaskan berdasarkan risiko, diberikan owner, diperbaiki, diuji ulang, dan didokumentasikan sampai benar-benar tertutup.
7. Bagaimana VAPT membantu mengurangi risiko aplikasi publik?
   VAPT membantu perusahaan melihat celah yang mungkin dimanfaatkan penyerang, memahami dampaknya, dan menentukan langkah perbaikan yang paling prioritas.