Örnek rapor

Örnek bir denetim raporu

Bir denetimden sonra elinize geçen şey budur: her bulgu, ciddiyeti, kanıtı, sade sözlerle riski ve bir önerisiyle.

Örnek: Bu rapor kurgusal bir uygulamayı anlatır. Gerçek bir müşteri, gerçek veri veya erişim bilgisi içermez.

Özet

Teknoloji: Next.js, Supabase, bir ödeme sağlayıcısı, Vercel üzerinde
Bulgular: Kritik: 1 Yüksek: 3 Orta: 3 Düşük: 2
Öneri: Yeniden yapmayın, sıkılaştırın. Oturum açma ve veri modeli sağlam; bulgular, kritik ve yüksek ciddiyetli olanlardan başlayarak odaklı iş paketlerinde giderilebilir.

Bulgular

F-01 invoices tablosunda satır erişimi korumasız

Kritik Alan: Güvenlik sıkılaştırma

Kanıt: invoices tablosunda satır düzeyi güvenlik devre dışı ve tarayıcı uygulamasıyla birlikte gelen herkese açık anahtar her satırı okuyabiliyor.
Risk: Herhangi bir ziyaretçi, adlar ve tutarlar dahil tüm müşterilerin faturalarını okuyabilir.
Öneri: Satır düzeyi güvenliği etkinleştirin, her satırı sahibiyle sınırlayan bir ilke ekleyin ve yayından önce iki hesapla test edin.

Kodsupabase/policies.sql

- -- henüz ilke yok (satır düzeyi güvenlik kapalı)+ alter table invoices enable row level security;+ create policy "owner reads own invoices" on invoices+   for select using (auth.uid() = user_id);

F-02 Hizmet anahtarı Git geçmişinde ve tarayıcı paketinde

Yüksek Alan: Güvenlik sıkılaştırma

Kanıt: Yönetici yetkisine sahip bir anahtar erken bir commit'te duruyor ve tarayıcıya gönderilen JavaScript'in içine derlenmiş.
Risk: Tarayıcının geliştirici araçlarını açan herkes veritabanında yönetici olarak işlem yapabilir.
Öneri: Anahtarı hemen yenileyin, geçmişten kaldırın ve onu gerektiren çağrıları, anahtarı ortamdan okuyan bir sunucu işlevine taşıyın.

Kodlib/supabase.ts

- const db = createClient(url, "sb_service_…")+ // yalnızca sunucu: bu modülü istemci kodunda asla içe aktarmayın+ const db = createClient(url, process.env.SUPABASE_SERVICE_KEY!)

F-03 Yönetici rotaları yalnızca tarayıcıda korunuyor

Yüksek Alan: Güvenlik sıkılaştırma

Kanıt: Yönetici menüsü normal kullanıcılar için gizlenmiş, ancak /api/admin altındaki API rotaları kullanıcının rolünü kontrol etmiyor.
Risk: Oturum açmış her kullanıcı yönetici işlevlerini doğrudan çağırabilir.
Öneri: Her yönetici rotasında rolü sunucuda kontrol edin ve rota başına, normal bir kullanıcı için reddedilmesini bekleyen bir test ekleyin.

F-04 Ödeme webhook'u sahte ve tekrarlanan istekleri kabul ediyor

Yüksek Alan: Kararlılık ve yeniden düzenleme

Kanıt: Webhook, ödeme sağlayıcısının imzasını doğrulamıyor ve yeniden denemeler dahil her teslimatta yeni bir fatura oluşturuyor.
Risk: Sahte bir istek bir faturayı ödenmiş olarak işaretleyebilir, bir yeniden deneme de aynı ödemeyi iki kez kaydeder.
Öneri: İmzayı doğrulayın, her olay kimliğini saklayın ve daha önce işlenmiş olayları yok sayın.

Kodapi/webhook.ts

  export async function POST(req: Request) {-   const event = await req.json()+   const event = verifySignature(req, process.env.WEBHOOK_SECRET!)+   if (await alreadyProcessed(event.id)) return new Response(null, { status: 200 })

F-05 Giriş ve parola sıfırlamada deneme sınırı yok

Orta Alan: Güvenlik sıkılaştırma

Kanıt: Giriş ve parola sıfırlama uç noktaları, adres ve hesap başına sınırsız sayıda denemeyi kabul ediyor.
Risk: Parolalar otomatik denemelerle tahmin edilebilir ve sıfırlama e-postası bir kullanıcıyı e-postaya boğmak için kullanılabilir.
Öneri: Denemeleri hesap ve adres başına sınırlayın, kısa bir kilitleme ekleyin ve tekrarlanan başarısızlıkları kullanıcıya bildirin.

F-06 Test yok, yaygın any tipleri ve kopyalanmış veri erişimi

Orta Alan: Kararlılık ve yeniden düzenleme

Kanıt: Otomatik test yok, işlevlerin çoğu any olarak tiplenmiş ve aynı sorgu birçok bileşene kopyalanmış.
Risk: Her değişiklik ilgisiz bir şeyi bozabilir ve bir kullanıcı bildirene kadar kimse fark edemez.
Öneri: Önce faturalama ve oturum açma etrafına testler ekleyin, veri katmanındaki any tiplerini değiştirin ve kopyalanan sorguları tek bir modüle taşıyın.

F-07 Hazırlama ortamı canlı veritabanını paylaşıyor, yedekler hiç geri yüklenmedi

Orta Alan: Production readiness ve işletim

Kanıt: Hazırlama sitesi canlı veritabanı adresiyle yapılandırılmış; yedekleme ayarı açık ama hiç geri yükleme denenmemiş.
Risk: Bir test müşteri verilerini yok edebilir ve hiç geri yüklenmemiş bir yedek, gerektiğinde çalışmayabilir.
Öneri: Hazırlama ortamına kendi veritabanını verin, en son yedeği bir kez ona geri yükleyin ve adımları yazın.

F-08 İki bağımlılıkta bilinen yüksek ciddiyetli güvenlik açığı

Düşük Alan: Denetim ve önceliklendirme

Kanıt: Bağımlılık denetimi, ikisi de dolaylı yoldan gelen, bilinen yüksek ciddiyetli güvenlik açığı bulunan iki paketi listeliyor.
Risk: Bilinen zayıflıklar, uygulamanın kendisi hakkında hiçbir bilgi olmadan istismar edilebilir.
Öneri: Paketleri güncelleyin veya değiştirin, otomatik güncelleme kontrollerini etkinleştirin ve her sürümden önce denetimi yeniden çalıştırın.

F-09 Hata izleme ve sağlık kontrolü yok

Düşük Alan: Production readiness ve işletim

Kanıt: Hatalar yalnızca tarayıcı konsolunda görünüyor ve bir izleyiciye uygulamanın ayakta olup olmadığını bildiren bir uç nokta yok.
Risk: Kesintileri ve başarısız ödemeleri önce müşteriler fark eder.
Öneri: Hata izleme, bir sağlık uç noktası ve bir kişiye giden bir uyarı ekleyin ve bunları hazırlama ortamında kontrol edin.

Bunu uygulamanız için ister misiniz?

Sabit kapsamlı bir denetimle başlarız. Kendi kodunuz için bunun gibi bir rapor alırsınız.

Denetim talep edin Ya da önce hazırlığınızı kontrol edin