1. API key tertanam di JavaScript frontend-mu
Ini kesalahan yang paling merusak sekaligus paling gampang dilakukan. Kamu meminta tool AI-mu untuk "menambahkan pembayaran Stripe" atau "terhubung ke OpenAI", dan ia menyambungkan secret key langsung ke sebuah komponen klien. Aplikasinya jalan — dan secret key-mu kini terkirim ke browser setiap pengunjung, bisa dibaca siapa pun yang membuka DevTools atau menyisir bundle JS-mu.
Apa pun yang berprefiks NEXT_PUBLIC_ (atau VITE_, atau REACT_APP_) tertanam ke bundle klien saat build. Secret key — Stripe sk_live_, OpenAI sk-, URL database, service-role key — hanya boleh dibaca di kode sisi server: API route, server component, atau edge function.
Cek cepatnya: buka situsmu yang sudah ter-deploy, lihat page source dan JS yang di-bundle, lalu cari sk_live, sk-, dan karakter-karakter awal key di .env-mu. Kalau ada yang muncul, rotasi dulu key-nya, baru pindahkan pemanggilannya ke sisi server.
2. .env atau .git disajikan langsung dari web root-mu
Jumlah aplikasi ter-deploy yang dengan senang hati mengembalikan file .env-nya — atau seluruh direktori .git-nya — hanya karena diminta itu mengejutkan. Cukup satu server file statis yang salah konfigurasi atau satu template framework yang menyalin semuanya ke folder public.
Dampaknya total: kredensial database, secret auth, API key, semua dalam satu file. Direktori .git yang terekspos hampir sama parahnya, karena penyerang bisa merekonstruksi seluruh riwayat kode sumbermu, termasuk secret yang pernah di-commit lalu "dihapus".
Cek cepatnya makan sepuluh detik:
curl -i https://yourapp.com/.env
curl -i https://yourapp.com/.git/config
# Both should return 404 (or 403) — never 200.3. Tidak ada Content-Security-Policy
Tool AI hampir tidak pernah menambahkan header keamanan, dan CSP adalah yang paling penting. Tanpanya, satu bug HTML-injection atau XSS di mana pun dalam aplikasimu memungkinkan penyerang menjalankan JavaScript sembarang di browser penggunamu — mencuri sesi dan mengekstrak data.
Policy awal yang baik untuk kebanyakan aplikasi: default-src 'self', blokir object dan framing, dan hanya izinkan origin script pihak ketiga yang benar-benar kamu pakai. Mulai dari yang ketat, longgarkan dengan sengaja — jangan pernah sebaliknya.
// next.config.js
const csp = [
"default-src 'self'",
"script-src 'self'",
"style-src 'self' 'unsafe-inline'",
"img-src 'self' data:",
"base-uri 'none'",
"frame-ancestors 'none'",
"object-src 'none'",
].join("; ");
module.exports = {
async headers() {
return [{ source: "/:path*", headers: [{ key: "Content-Security-Policy", value: csp }] }];
},
};4. Cookie sesi tanpa Secure, HttpOnly, dan SameSite
Kalau library auth-mu disambungkan oleh tool AI dengan opsi default, ada baiknya memverifikasi flag cookie sesi. Cookie tanpa HttpOnly bisa dibaca script sisipan apa pun (mengubah XSS kecil menjadi pengambilalihan akun penuh), tanpa Secure bisa bocor lewat HTTP biasa, dan tanpa SameSite membuat cross-site request forgery jauh lebih mudah.
Buka DevTools → Application → Cookies di aplikasimu yang sudah ter-deploy. Setiap cookie sesi atau auth seharusnya menampilkan ketiganya: Secure, HttpOnly, dan SameSite=Lax (atau Strict).
5. HTTP yang tak pernah jadi HTTPS (dan tanpa HSTS)
Kebanyakan platform hosting memberimu HTTPS otomatis — tapi banyak aplikasi masih menjawab dengan senang hati di HTTP biasa tanpa redirect, atau redirect tapi tak pernah mengirim header Strict-Transport-Security. Bagaimana pun caranya, pengguna yang mengetik domainmu di address bar membuat request pertamanya tak terenkripsi, dan request itu bisa disadap atau di-downgrade sebelum redirect-mu terjadi.
Perbaikannya dua baris konfigurasi: redirect permanen 301 dari HTTP ke HTTPS, plus header HSTS (max-age=31536000; includeSubDomains) agar browser menolak menurunkan koneksi lagi.
6. CORS disetel mengizinkan segalanya
Saat frontend buatan AI tidak bisa menjangkau API-nya sendiri saat pengembangan, "perbaikan" yang dihasilkan hampir selalu Access-Control-Allow-Origin: * — kadang dengan credentials diizinkan juga. Itu memberi tahu setiap situs di internet bahwa mereka boleh memanggil API-mu dari browser pengunjungnya.
Untuk API yang menyajikan frontend-mu sendiri, origin yang diizinkan seharusnya tepat domainmu sendiri, dan tidak lebih. Wildcard CORS hanya bisa diterima untuk API yang benar-benar publik, tanpa autentikasi, dan read-only.
7. Tidak ada SPF atau DMARC di domainmu
Yang satu ini sama sekali bukan soal kode aplikasimu — ini soal domainmu. Tanpa record DNS SPF dan DMARC, siapa pun bisa mengirim email yang mengaku dari [email protected], dan server email penerima tidak punya cara untuk tahu itu palsu. Itu phishing terhadap penggunamu sendiri, memakai brand-mu.
Dua record DNS TXT memperbaikinya. Kalau kamu mengirim email lewat provider seperti Resend, Postmark, atau SES, dokumentasi mereka memberimu nilai SPF yang tepat; tambahkan policy DMARC di sampingnya dan perketat dari p=none ke p=quarantine setelah kamu memastikan email yang sah lolos.
Cek ketujuhnya sekaligus dalam sekali jalan
Setiap item di daftar ini bisa dideteksi dari luar, artinya kamu tidak perlu menelusurinya satu per satu secara manual. AppSafe menjalankan semua pemeriksaan ini — plus SSL/TLS, subdomain takeover, source map, dan lainnya — dalam satu pemindaian, memberi Nilai A–F pada hasilnya, dan memberimu prompt perbaikan AI untuk setiap temuan yang bisa langsung kamu tempel kembali ke Cursor atau Claude Code.
Pemindaian cepat di halaman utama tidak butuh pendaftaran. Pemindaian penuh (termasuk pemeriksaan exposed-secrets) hanya berjalan di domain yang sudah kamu verifikasi kepemilikannya — memang disengaja, karena kami tidak akan menyisir bundle JS milik orang lain untuk mencari key.