Claude Code'da hassas bağlamı azaltarak daha güvenli kod yardımı

Kod yardımı isterken bağlamı azaltmanın önemi

“Bağlam”, modelle paylaştığınız her şeydir: kod parçaları, stack trace'ler, konfig dosyaları, ortam değişkenleri, veritabanı örnekleri, ekran görüntüleri ve aynı sohbet içindeki önceki mesajlar. Daha fazla bağlam hata ayıklamayı hızlandırabilir, ancak istemeden paylaşacağınız bir şeyi yapıştırma olasılığını da artırır.

Aşırı paylaşım genellikle baskı altında olur. Bir hata bir yayını engelliyor, oturum açma bir demo öncesinde bozuluyor ya da flakiy test yalnızca CI'de hata veriyor olabilir. O anda tüm dosyayı, sonra tüm logu, sonra tüm konfigüru "tedbir amaçlı" yapıştırmak kolaydır. Ekip alışkanlıkları da aynı yönde itebilir: kod incelemede ve hata ayıklamada tam görünürlük normaldir, oysa yalnızca küçük bir parça gereklidir.

Riskler teorik değil. Tek bir yapıştırma gizli bilgileri, müşteri verilerini veya iç sistem detaylarını sızdırabilir. Yaygın örnekler şunlardır:

• API anahtarları, tokenlar, özel anahtarlar, oturum cookie'leri
• İç URL'ler, IP'ler, host isimleri ve servis adları
• Loglardaki müşteri verileri (e-postalar, isimler, ID'ler, ödemeler)
• Yayınlamadığınız iş mantığı (fiyatlandırma kuralları, dolandırıcılık kontrolleri)
• Güvenlik detayları (admin endpoint'leri, feature flag'ler, erişim desenleri)

Amaç gizemli olmak değil. Sorunu çoğaltacak veya kararı açıklayacak en küçük parçayı paylaşmaktır; böylece aynı kalitede yardım alır, ama daha az maruziyet yaşarsınız.

Basit bir zihinsel model: asistana tüm repoyu bilmesi gereken yardımcı dış ekip arkadaşı gibi davranmayın. Önce tek ve kesin bir soru ile başlayın (“Neden bu istek 401 dönüyor?”). Sonra bu soruyu destekleyenleri paylaşın: başarısız girdi, beklenen çıktı, gerçek çıktı ve ilgili dar kod yolu.

Bir giriş çağrısı başarısız oluyorsa, genellikle tüm auth modülünü paylaşmanıza gerek yoktur. Bir sanitizelenmiş istek/yanıt çifti, başlıkları oluşturan fonksiyon ve ilgili konfig anahtarları (değerler yerine yer tutucularla) çoğu durumda yeterlidir.

Hassas bağlam nedir (ve unutulanlar)

Kod yardımı isterken “bağlam” sadece kaynak kod değildir. Birine giriş yapma, bir kişiyi tanımlama veya sistemlerinizi eşleme imkanı verebilecek her şeydir. Önce neyin toksik olduğunu bilin.

Bariz olan: gizli bilgiler ve kimlik bilgileri

Kimlik bilgileri yardımcı bir parçayı bir olay haline getirir. Buna API anahtarları ve tokenlar, özel anahtarlar, session cookie'leri, imzalanmış URL'ler, OAuth istemci sırları, veritabanı parolaları ve loglarda yazdırılan “geçici” tokenlar dahildir.

Dolaylı sızıntılar sürpriz olabilir. Bir hata mesajı Authorization bearer token içeren tam istek header'larını veya ortam değişkenlerinin debug çıktısını içerebilir.

Kişisel ve düzenlemeye tabi veriler

Bir kişiye bağlı her veri hassas olabilir, tek başına zararsız görünse bile. E-postalar, isimler, telefon numaraları, adresler, müşteri ID'leri, çalışan ID'leri, destek ticket'ları ve ödeme detaylarına dikkat edin.

Bir hatayı çoğaltmak için veriye ihtiyaç varsa, gerçek kayıtları gerçek değerleri yerine gerçekçi sahte verilerle değiştirin. Şekli (alanlar ve tipler) koruyun, kimliği değil.

Organizasyonunuzu eşleyen iç detaylar

“Sıkıcı” iç bilgiler saldırganlar ve rakipler için değerlidir: host isimleri, IP'ler, repo isimleri, ticket ID'leri, tedarikçi isimleri, sözleşme koşulları ve iç servis URL'leri.

Tek bir stack trace bile klasör yollarında kullanıcı adlarını veya müşteri isimlerini, servis adlandırma konvansiyonlarını ve bulut hesap ipuçlarını (bucket isimleri, bölge dizeleri) açığa çıkarabilir.

Tescilli mantık ve “gizli sos”

Tüm kod aynı derecede hassas değildir. En riskli parçalar işinizin nasıl çalıştığını kodlayanlardır: fiyatlama ve indirim kuralları, dolandırıcılık kontrolleri, öneri mantığı, LLM özellikleri için prompt şablonları ve stratejik dokümanlar.

Bir hata için yardım istiyorsanız, tüm modülü değil hatayı yeniden üreten en küçük fonksiyonu paylaşın.

İnsanların unuttuğu meta veriler

Hassas detaylar çoğu zaman fark etmediğiniz yerlerde gezer: içeren yorumlar, commit mesajları, müşteriye referans veren TODO'lar ve olduğu gibi yapıştırılmış stack trace'ler. Konfig dosyaları özellikle risklidir çünkü masum ayarlarla gizlileri karıştırırlar.

Pratik bir kural: metin, temiz bir örneğin sisteminizi daha hızlı anlamasına yardımcı oluyorsa, onu hassas kabul edin ve sansürleyin veya değiştiriş yapın.

Yapıştırmadan önce paylaşmanız gereken en az şeyi seçin

Maruz kalmayı azaltmanın en iyi zamanı editörünüzü açmadan önce. Sonuçtan 30 saniyelik bir düşünme çoğu şeyi azaltır.

İsteneni bir cümlede adlandırarak başlayın. Bir hatanın nedenini mi bulmaya çalışıyorsunuz, güvenli bir refactor planı mı istiyorsunuz yoksa test tasarımı mı? Her hedef farklı girdiler gerektirir. Hata avları genellikle tek bir stack trace ve küçük bir fonksiyon gerektirir. Refactor soruları genellikle yalnızca public arayüzleri ve kısa bir kullanım örneğini ister.

Sonra problemi kanıtlayan bir “minimal artefakt” seçin. Hataları tetikleyen en küçük şeyi seçin: tek başarısız test, hatayı tetikleyen en küçük snippet, başarısızlığın etrafından kısa bir log alıntısı veya yer tutucular içeren basitleştirilmiş bir konfig örneği.

Verileri tanımlarken, değerler yerine şekillere öncelik verin. “Kullanıcı nesnesi: id (UUID), email (string), role (enum), createdAt (timestamp)” genelde yeterlidir. Örnekler gerekiyorsa, formatı eşleyen sahte veriler kullanın, gerçek kayıtları değil.

Dosyalar konusunda katı olun. Yalnızca değiştirdiğiniz modülü ve etkileştiği arayüzleri paylaşın. Bir fonksiyon başka bir modüle çağrı yapıyorsa genellikle yalnızca imzayı ve döndürdüğü şeyin kısa bir açıklamasını paylaşmanız yeterlidir. Bir hata başka bir servise yapılan bir isteği içeriyorsa, genellikle sadece istek şekli, header isimlerinin listesi (değerler değil) ve beklenen yanıt şekli yeterli olur.

Bilgisayarınızdan asla çıkmayacak sert sınırlar belirleyin: API anahtarları, özel sertifikalar, erişim tokenları, müşteri verileri, iç URL'ler, tam repo dökümleri ve ham üretim logları. Eğer 401 hatasını debug ediyorsanız, auth akışını ve hata mesajını paylaşın, ama tokenı TOKEN_REDACTED ile ve e-postayı [email protected] ile değiştirin.

Kod ve logları işe yarar tutan sansür desenleri

İyi sansür sadece gizlileri gizlemek değildir. Problemin yapısını korur, böylece asistan hala mantık yürütebilir. Çok fazlasını kaldırırsanız genel tavsiye alırsınız; çok azını kaldırırsanız veri sızdırırsınız.

Desen 1: Tutarlı yer tutucular kullanın

Bir yer tutucu stili seçin ve kod, konfig ve loglarda tutarlı kullanın. Tutarlılık akışı takip etmeyi kolaylaştırır.

Aynı token üç yerde görünüyorsa, üç farklı şekilde değiştirmeyin. API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 gibi yer tutucular kullanın ve gerektiğinde numaralandırın (TOKEN_2, TOKEN_3).

Kısa bir efsane yardımcı olur:

• TOKEN_1: Authorization header'da kullanılan bearer token
• CUSTOMER_ID_1: veritabanı aramasında kullanılan dahili müşteri kimliği
• API_KEY_1: ödeme sağlayıcısına çağrı yaparken kullanılan anahtar

Desen 2: Format önemliyse formatı koruyun

Bazı hatalar uzunluk ve yapıya bağlıdır (parsing, doğrulama, imza kontrolleri, regex). Bu durumlarda benzeyen dummy değerler kullanın.

Örneğin:

• JWT-benzeri tokenlar: üç nokta ile ayrılmış bölümleri ve benzer uzunlukları koruyun
• UUID-benzeri stringler: 8-4-4-4-12 desenini koruyun
• Base64-benzeri bloblar: benzer karakter seti ve yaklaşık uzunluk

Bu sayede “token doğrulama hatası alıyorum” diyebilirsiniz, gerçek tokenı ifşa etmeden.

Desen 3: Değerleri sansürleyin ama yapıyı bırakın

JSON paylaşırken anahtarları bırakın ve değerleri değiştirin. Anahtarlar sistemin ne beklediğini gösterir; değerler genellikle hassastır.

Yerine koyma örneği:

{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}

SQL için de aynı fikir geçerli: tablo isimlerini, joinleri ve koşulları tutun ama literal değerleri kaldırın.

• Koru: WHERE user_id = USER_ID_1 AND created_at > DATE_1
• Kaldır: gerçek ID'ler, zaman damgaları, e-postalar, adresler

Desen 4: Hassas blokları yapıştırmak yerine özetleyin

Bir fonksiyon iş kuralları veya tescilli mantık içeriyorsa, onu tanımlayın. Hatanın neyi etkilediğini tutun: girdi, çıktı, yan etkiler ve hata ele alma.

Örnek özet:

“signRequest(payload) bir JSON payload alır, timestamp ve nonce ekler, sonra method + path + body'den HMAC SHA-256 imzası oluşturur. {headers, body} döndürür. Hata payload non-ASCII karakter içerdiğinde oluşuyor.”

Bu genelde kodun tam implementasyonunu açığa çıkarmadan kodlama, canonicalization ve imza uyuşmazlıklarını teşhis etmeye yeter.

Desen 5: Kısa bir sansür notu ekleyin

İsteminizin sonunda neyi kaldırdığınızı ve neyi bıraktığınızı belirtin. Bu tur-söhbette geri dönüşleri azaltır ve daha fazlasının istenme olasılığını düşürür.

Örnek:

“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”

Aşırı paylaşmadan yine de cevap alan istem desenleri

Asistanı yalnızca aktif olarak üzerinde çalıştığınız parçayı bilmesi gereken bir iş arkadaşı gibi ele alın. Tüm dosyaları paylaşmak yerine arayüzleri ve kontratları paylaşın: fonksiyon imzaları, tipler, istek/yanıt şekilleri ve kesin hata metni.

Açık dilde küçük bir yeniden üretme genelde yeterlidir: kullandığınız girdi, beklenen çıktı, gerçekleşen ve birkaç ortam notu (runtime sürümü, OS, framework sürümü). Proje geçmişinize gerek yoktur.

Etkili olma eğilimindeki şablonlar:

• “Bu fonksiyon imzası ve çağıranı verildiğinde, bu hatanın en olası nedenleri nelerdir ve önce neyi kontrol etmeliyim?” (sadece ilgili fonksiyon ve nereden çağrıldığı olsun)
• “Bu isteği gönderiyorum (sansürlenmiş) ve bu yanıtı alıyorum (sansürlenmiş). Sunucu neden bu status kodunu döndürüyor olabilir?” (header isimlerini ekleyin, auth değerlerini kaldırın)
• “İşte repro adımları, beklenen vs gerçek çıktı ve ortam. Sorunu izole etmek için 3 odaklı deney öner.”
• “Bu log alıntısı hatayı ve etrafındaki 10 satırı gösteriyor. En basit açıklama nedir ve hangi ekstra bir log satırını eklemeliyim?”
• “İşte soruna ilişkin hangi anahtarların olduğu gösteren sansürlenmiş konfig. Bu soruna muhtemelen hangileri yanlış ayarlı?” (anahtarlar, değerler değil)

Sansürlenmiş bir konfig blok'u iyi bir orta yol sağlar: hangi düğmelerin olduğunu gösterir, gizlileri açığa çıkarmadan.

# sanitized
DB_HOST: "\u003cset\u003e"
DB_PORT: "5432"
DB_USER: "\u003cset\u003e"
DB_PASSWORD: "\u003credacted\u003e"
JWT_SECRET: "\u003credacted\u003e"
OAUTH_CLIENT_ID: "\u003cset\u003e"
OAUTH_CLIENT_SECRET: "\u003credacted\u003e"

Güvenli bir örnek istem:

“Giriş 401 dönüyor. Beklenen 200. Gerçek yanıt gövdesi: ‘invalid token’. Ortam: Node 20, local dev, zaman senkronizasyonu etkin. İstek kontratı: Authorization: Bearer \u003credacted\u003e. Doğrulama adımları: token /auth/login tarafından veriliyor ve /me üzerinde kullanılıyor. En olası sebepler nelerdir (clock skew, audience mismatch, signing secret mismatch) ve her biri için hangi tek kontrol bunu doğrular?”

Kod yardımı için güvenli dosya paylaşma iş akışı

Güvenilir bir alışkanlık, paylaşmayı küçük bir reproducible paket olarak ele almaktır. Sorunu teşhis edecek kadar paylaşın, daha fazlasını değil.

Pratik bir yol, gerçek repodan ayrı geçici bir “share folder” tutmaktır. Dosyaları manuel olarak oraya kopyalayın; bu kasıtlı seçimleri zorunlu kılar.

İş akışını basit tutun:

• Yalnızca sorunu yeniden üreten dosyaları kopyalayın (genellikle 1–3 dosya ve bir konfig şablonu).
• Kısa bir README-benzeri not ekleyin: beklenen davranış, gerçek davranış, nasıl çalıştırılacağı, neyin bilerek eksik olduğu.
• Gizli bilgileri ve endpoint'leri stub'layın: gerçek tokenları, anahtarları ve host isimlerini yer tutucular veya örnek domainler/localhost portları ile değiştirin.
• Veri gerekiyorsa küçük bir sentetik fixture (ör. 10–20 satır sahte e-postalar ve sahte ID'ler) ekleyin; veritabanı dökümü değil.
• “İhtimal için” olan her şeyi çıkarın: eski loglar, alakasız modüller, çift versiyonlar.

Klasör oluşturduktan sonra dışarıdan birisi gibi okuyun. Bir dosya spesifik problemi çözmeye yardımcı olmuyorsa, orada olmamalıdır.

Sansürlerken kodun veya logların bozulmasından kaçının. Değerleri type ve yapıyı koruyan bariz yer tutucularla değiştirin. Örnek:

DATABASE_URL=postgres://user:[email protected]:5432/app

ile

DATABASE_URL=postgres://user:REDACTED@localhost:5432/app

Değişiklik üçüncü taraf yanıtına bağlıysa, README'de yanıt şekline dair not yazın ve eşleşen sentetik bir JSON dosyası ekleyin. Gerçek trafik paylaşmadan anlamlı hata ayıklama yapabilirsiniz.

Adım adım: gizlilik-öncelikli yardım isteme iş akışı

Tekrar edilebilir bir döngü kullanın ki baskı altında doğaçlama yapmayın.

1. Önce iki cümle yazın.

   • Problem bildirimi: ne bozuldu, düz bir dille.
   • Sınır: neyi paylaşmayacağınız (ör. “No API keys, no customer data, no internal hostnames”).

2. Minimum girdileri toplayın. Yalnızca yeniden üretmeye veya sorunu mantıksal olarak incelemeye yardımcı olacakları getirin: başarısız satır etrafındaki küçük bir snippet, kesin hata metni, ilgili sürümler ve 3–5 repro adımı.

3. Yapıyı bozmadan sansürleyin. Gizli bilgileri yer tutucularla değiştirin ve şekli koruyun. Davranışı etkilemeyen kimlikleri (proje isimleri, tenant ID'leri, e-postalar) kaldırın. Yer tutucuları tutarlı kullanın.

   API_KEY=sk_live_...
   becomes
   API_KEY=\u003cAPI_KEY\u003e
   
   customer-1234-prod-db
   becomes
   \u003cDB_HOST_PROD\u003e
   

4. Hedeflenen sorular sorun. “En olası neden nedir?” ile “Ne değiştirmeliyim?”ı eşleştirin. Yama istiyorsanız, sağladığınız snippet ile sınırlı bir değişiklik isteyin ve varsayımların etiketlenmesini talep edin.

5. Yerelde doğrulayın, sonra bir ayrıntı daha ekleyin. Öneriyi test edin. Başarısız olursa, yalnızca bir yeni bilgi ekleyin (bir sonraki stack trace satırı, bir konfig bayrağı, daraltılmış bir repro). Doğrudan tüm dosyayı yapıştırmayın.

Bu kademeli açıklama genelde gerçek bir cevap almanızı sağlar ve gizli bilgileri sohbetten uzak tutar.

Örnek: gizli bilgileri açığa çıkarmadan bir auth hatasını debug etme

Yaygın bir durum: laptopta ve staging'de giriş çalışıyor, ama üretimde başarısız oluyor. Hemen yardım gerekir, fakat gerçek tokenları, kullanıcı e-postalarını, iç host isimlerini veya tam auth middleware'ini yapıştıramazsınız.

Başlangıç olarak gözlemleyebildiğiniz şeyleri paylaşın: istek ve yanıt şekli, status kodu ve kısa bir stack trace. JWT ile ilgiliyse, hassas olmayan header detaylarını (beklenen algoritma gibi) ve zamanla ilgili notları paylaşabilirsiniz. Geri kalan her şeyi yer tutucularla değiştirin.

Güvenli bir paket genelde şunları içerir:

• İstek: metod, path, genel header'lar (Authorization: "Bearer \u003cJWT_REDACTED\u003e"), body alan isimleri (gerçek değerler yok)
• Yanıt: status (401/403), genel hata kodu/mesajı ve kullanıcıyla bağlantılı olmayan bir correlation id varsa o
• Loglar: başarısızlığın etrafındaki 5–10 satır, tokenlar/e-postalar/hostlar sansürlenmiş
• Stack trace: doğrulamanın nerede başarısız olduğunu gösteren üst frame'ler

Sonra odaklanmış bir soru sorun. Prod-özel auth hataları genelde clock skew, yanlış issuer/audience, farklı imza anahtarları, anahtar rotasyon eksikliği veya proxy/header farklılıklarından kaynaklanır.

İstem deseni:

I have a production-only login/auth failure. Locally it passes.

Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200

Sanitized request/response:
- Authorization: Bearer \u003cJWT_REDACTED\u003e
- Expected claims: iss=\u003cISSUER_PLACEHOLDER\u003e, aud=\u003cAUDIENCE_PLACEHOLDER\u003e
- Token validation library: \u003cLIB_NAME_AND_VERSION\u003e

Sanitized log snippet:
\u003cPASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED\u003e

Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?

Hipotezleri aldıktan sonra güvenli şekilde doğrulamalar yapın. Sadece hassas olmayan gerçekleri (exp, iat, now ve başarısızlık neden kodu) yazan geçici loglama ekleyin. Bilinçli bir test yazın: bilinen-güvenli bir token fixture'ı ile doğrulayıcı davranışı sınayın. Geçerli sonucu doğruladıktan sonra geçici logları kaldırın.

Basit bir plan:

• Sunucu zamanını ve token exp/iat değerlerini loglayın (ham tokenı asla değil)
• Üretimde issuer/audience/env konfig değerlerini (hash veya sansürlü string olarak) doğrulayın
• Clock skew toleransı için bir test ekleyin (ör. 60–120 saniye)
• Güvenli bir ortamda üretilmiş sentetik token ile yeniden üretin
• Onaylandıktan sonra geçici logları kaldırın

Kaçınılması gereken yaygın hatalar

Mahremiyete dair faydayı hızlı şekilde kaybetmenin en kolay yolu “küçük bir şey” yapıştırırken içeriğin her şeyi barındırmasıdır. Tam .env veya konfig dosyasını yapıştırmak klasik örnektir. Belki açık gizlileri sildiğinizi düşünürsünüz, ama bu dosyalar genellikle iç host isimleri, servis isimleri, feature flag'leri ve ortam ipuçlarını içerir.

Tam stack trace'ler sıkça bilgi sızdırır. Kullanıcı adları, makine isimleri, repo isimleri ve /Users/alex/company-payments/... gibi mutlak yollar içerebilirler. Trace gerekiyorsa, sadece ilgili frame'leri kopyalayın ve yolları tutarlı yer tutucularla değiştirin.

Gerçek müşteri yükleri “küçük” görünseler bile risklidir. Tek bir JSON gövdesi e-postalar, adresler, sipariş ID'leri veya serbest metin notları içerebilir. Daha güvenli hareket, aynı şekil ve sınır durumları (eksik alanlar, uzun dizeler, garip karakterler) içeren sahte yük oluşturmaktır.

Tutarsız yer tutucular da sorun çıkarır. Eğer USER_ID bir yerde “müşteri id” ve başka yerde “iç hesap id” anlamına geliyorsa yanlış teşhis alırsınız. Bir şema seçin ve ona sadık kalın.

Mesajınız bir yabancının giriş yapmasına, sunucularınızı bulmasına veya bir müşteriyi tanımlamasına yardımcı olacaksa, bir tur daha sansürleyin.

Hızlı kontrol listesi ve sonraki adımlar

Dikkatli olmaya çalışırken hız düşmanınızdır. Kısa bir rutin, yararlı cevaplar alırken hassas verileri dışarıda tutmanıza yardımcı olur.

İlk turda gizlilere bakın, ikinci turda sistemi açığa çıkaran tanımlayıcıları sansürleyin:

• Erişim sağlayan her şeyi kaldırın: API anahtarları, OAuth istemci sırları, özel anahtarlar, session cookie'leri, refresh tokenlar, auth header'ları.
• Gizli erişim yollarını temizleyin: imzalanmış URL'ler, pre-signed upload linkleri, webhook sırları, parola sıfırlama linkleri, davet linkleri.
• İç tanımlayıcıları değiştirin: iç domainler, host isimleri, IP'ler, hesap ID'leri, kullanıcı ID'leri, organizasyon ID'leri, sipariş ID'leri, ticket numaraları.
• Logları sanitize edin: istek gövdeleri, query string'ler, dosya yolları içeren stack trace'ler, kullanıcı isimleri veya ortam değişkenleri.
• Kapsamın minimal olduğunu onaylayın: sadece başarısız yol, çağıran ve girdi/çıktı kontratı.

Sansürledikten sonra yapıyı koruyun. Tipleri, şemaları, alan isimlerini, status kodlarını ve örnek yük yapılarını bırakın; gerçek değerleri yer tutucularla değiştirin.

Baskı altında da tutarlı kalmak için küçük bir sansür kural seti yazın ve yeniden kullanın. Ekipler için bunu iki bloklu bir şablona çevirin: “paylaşıyorum” (dosyalar, fonksiyonlar, endpoint'ler) ve “paylaşmıyorum” (gizli anahtarlar, üretim verileri, iç domainler).

Ek güvenlik için deneyleri izole bir ortamda yapın ve değişiklikleri geri alınabilir tutun. Koder.ai (koder.ai) içinde planning mode, bir hipotezi test etmek için gereken en küçük değişikliği tasarlamanıza ve snapshot/rollback ile riskleri azaltmanıza yardımcı olabilir.