Sorun: Hata kaydında hassas verinin sızması
Kurgusal bir ödeme akışında hata ayrıntıları loglanıyor:
Bu kod, hata sırasında tüm istek dizisini logluyor olabilir. İstek içinde password, card_number, cvv veya oturum belirteci bulunuyorsa hassas veri düz metin olarak kaydedilebilir. Sorun yalnızca üretim loglarında değil; log toplayıcıları, hata izleme hizmetleri ve yedekler de aynı veriyi çoğaltabilir.
AI kod incelemesine şu bağlamla sorulabilir: “Bu log kaydı hassas veri içeriyor mu? Hangi alanlar maskeleme gerektirir ve mevcut işlevselliği bozmadan en küçük düzeltmeyi öner?” Ancak model, dizinin çalışma zamanında hangi alanları içerdiğini kesin olarak bilemez. Yalnızca alan adlarına bakarak karar verebilir ve örneğin payment_token gibi özel bir alanı atlayabilir. Bu nedenle öneri tek başına kanıt sayılmamalıdır.
Asgari düzeltme ve tasarım noktaları
Ham isteği loglamak yerine izin verilen alanları seçmek daha güvenlidir:
İzin verilen alan yaklaşımı, “hassas olmayan her şeyi logla” yaklaşımından daha sağlamdır. İş gereği bir değerin kısmen görünmesi gerekiyorsa maskeleme açıkça tanımlanmalıdır; örneğin kart numarasının yalnızca son dört hanesi tutulabilir. CVV, parola, erişim belirteci ve tam ödeme bilgileri loglanmamalıdır. Exception mesajı da ayrıca incelenmelidir; harici kütüphaneler mesajın içine istek ayrıntısı ekleyebilir.
AI önerisini doğrulama adımları
Kurgusal bir ödeme akışında hata ayrıntıları loglanıyor:
function logPaymentError(array $request, Throwable $e): void
{
error_log(json_encode([
'request' => $request,
'error' => $e->getMessage(),
]));
}Bu kod, hata sırasında tüm istek dizisini logluyor olabilir. İstek içinde password, card_number, cvv veya oturum belirteci bulunuyorsa hassas veri düz metin olarak kaydedilebilir. Sorun yalnızca üretim loglarında değil; log toplayıcıları, hata izleme hizmetleri ve yedekler de aynı veriyi çoğaltabilir.
AI kod incelemesine şu bağlamla sorulabilir: “Bu log kaydı hassas veri içeriyor mu? Hangi alanlar maskeleme gerektirir ve mevcut işlevselliği bozmadan en küçük düzeltmeyi öner?” Ancak model, dizinin çalışma zamanında hangi alanları içerdiğini kesin olarak bilemez. Yalnızca alan adlarına bakarak karar verebilir ve örneğin payment_token gibi özel bir alanı atlayabilir. Bu nedenle öneri tek başına kanıt sayılmamalıdır.
Asgari düzeltme ve tasarım noktaları
Ham isteği loglamak yerine izin verilen alanları seçmek daha güvenlidir:
function logPaymentError(array $request, Throwable $e): void
{
$safe = [
'order_id' => $request['order_id'] ?? null,
'user_id' => $request['user_id'] ?? null,
'currency' => $request['currency'] ?? null,
];
error_log(json_encode([
'request' => $safe,
'error' => 'Payment processing failed',
], JSON_THROW_ON_ERROR));
}İzin verilen alan yaklaşımı, “hassas olmayan her şeyi logla” yaklaşımından daha sağlamdır. İş gereği bir değerin kısmen görünmesi gerekiyorsa maskeleme açıkça tanımlanmalıdır; örneğin kart numarasının yalnızca son dört hanesi tutulabilir. CVV, parola, erişim belirteci ve tam ödeme bilgileri loglanmamalıdır. Exception mesajı da ayrıca incelenmelidir; harici kütüphaneler mesajın içine istek ayrıntısı ekleyebilir.
AI önerisini doğrulama adımları
- Bir test isteğine parola, CVV, sahte kart numarası ve token benzeri alanlar ekleyin.
- İşlevi çalıştırıp üretilen log metninde bu değerlerin bulunmadığını doğrulayın.
- Exception mesajı, stack trace ve bağlı hata izleme gönderimini ayrı ayrı kontrol edin.
- Kod incelemesinde kullanılan alan listesini gerçek istek DTO’ları ve yapılandırmayla karşılaştırın.
- Gerekirse otomatik testte hassas örnek değerlerin log çıktısında geçmesini başarısızlık kabul edin.