August 23, 2026

IDOR’u Anlamak:

Bir ID Değişikliğinin Yetki Kontrolünü Ortaya Çıkarması

By Sena Şahin

8 min read

Bir ID Değişikliğinin Yetki Kontrolünü Ortaya Çıkarması

Web uygulamalarında güvenlik testi yaparken karşılaşılan problemlerin tamamı karmaşık exploit'lerden oluşmuyor. Bazen kritik bir güvenlik açığı, URL içerisinde bulunan tek bir sayının değiştirilmesi kadar basit bir davranıştan ortaya çıkabiliyor.

Örneğin bir uygulamada şu endpoint'in bulunduğunu düşünelim:

GET /api/users/125/orders/348

Kullanıcı kendi siparişini görebiliyor.

Peki aynı kullanıcı:

GET /api/users/125/orders/349

gönderdiğinde başka bir kullanıcının siparişini görebiliyorsa?

Buradaki problem ID'nin tahmin edilebilir olması değil. Asıl problem, sunucunun kullanıcının 349 numaralı kaynağa erişme yetkisini kontrol etmemesi.

Bu zafiyet sınıfı genellikle IDOR — Insecure Direct Object Reference olarak adlandırılıyor.

IDOR'u anlamak için önce authentication ve authorization arasındaki farkı anlamak gerekiyor.

Authentication ve Authorization Aynı Şey Değil

Bu iki kavram web güvenliğinde sürekli birlikte geçse de farklı problemleri çözer.

Authentication:

"Sen kimsin?"

Örneğin kullanıcı login olduğunda uygulama onun Sena olduğunu doğrular.

Authorization:

"Bunu yapmaya yetkin var mı?"

Örneğin Sena sisteme giriş yapmış olabilir. Ancak bu, başka bir kullanıcının özel mesajlarını veya siparişlerini görme yetkisine sahip olduğu anlamına gelmez.

IDOR genellikle authentication'ın çalıştığı ama authorization kontrolünün eksik olduğu durumlarda ortaya çıkar.

Yani uygulama saldırganı tanıyor olabilir.

Sorun, tanıdığı kullanıcıya olmaması gereken kaynağı vermesidir.

IDOR Nedir?

IDOR, bir uygulamanın kullanıcı tarafından doğrudan erişilebilen bir nesne referansını yeterli yetki kontrolü yapmadan kullanmasıdır.

Buradaki "object" kelimesi sadece veritabanındaki bir satır anlamına gelmez.

Şunların tamamı birer kaynak olabilir:

  • Kullanıcı profili
  • Sipariş
  • Fatura
  • Bilet
  • Özel mesaj
  • Dosya
  • Fotoğraf
  • Rapor
  • Rezervasyon
  • API kaydı
  • Proje

Örneğin:

GET /api/invoices/1001

isteği kullanıcının kendi faturasını döndürüyor.

Kullanıcı:

GET /api/invoices/1002

gönderdiğinde başka bir müşterinin faturası dönüyorsa, burada ciddi bir authorization problemi olabilir.

Burada önemli nokta şudur:

1002'nin tahmin edilebilir olması zafiyetin kendisi değildir.

Asıl problem:

Kullanıcının 1002 numaralı faturaya erişme yetkisi olmadığı halde sunucunun bunu engellememesidir.

IDOR'un Temel Mantığı

Bir IDOR açığını anlamanın en kolay yolu üç parçalı bir model kurmaktır:

Kullanıcı
   ↓
İstek
   ↓
Kaynak

Örneğin:

GET /api/orders/348
Authorization: Bearer <token>

Sunucu şu mantığı uygulamalıdır:

348 numaralı sipariş var mı?
        ↓
Evet
        ↓
Bu sipariş mevcut kullanıcıya ait mi?
        ↓
Evet → Göster
Hayır → Reddet

Güvensiz uygulamalarda ise kontrol şu kadar basit olabilir:

SELECT * FROM orders WHERE id = 348;

Burada id=348 kaydı bulunuyorsa sonuç kullanıcıya gönderilir.

Eksik olan şey:

Bu kaynağın sahibi kim?
Bu kullanıcı bu kaynağa erişebilir mi?

Dolayısıyla IDOR çoğu zaman bir veritabanı sorgusu problemi değil, authorization mantığı problemidir.

IDOR Nasıl Tespit Edilir?

IDOR testi yaparken ilk iş rastgele ID değiştirmek değildir.

Öncelikle uygulamanın kaynakları nasıl referansladığını anlamak gerekir.

Örneğin:

GET /profile/152
GET /orders/824
GET /invoice/391
GET /files/912

gibi endpoint'ler incelenebilir.

Burada özellikle kullanıcıya ait nesnelerin doğrudan bir identifier ile çağrıldığı noktalar önemlidir.

Identifier şunlardan biri olabilir:

id=123
user_id=42
order_id=812
document_id=391
account=17

veya URL içerisinde:

/users/42
/orders/812
/documents/391

şeklinde bulunabilir.

Ancak IDOR sadece URL'deki sayılarda aranmaz.

Request body içerisinde de olabilir:

{
  "user_id": 42,
  "document_id": 391
}

Bu yüzden test sırasında yalnızca browser URL'sine bakmak yeterli değildir.

En Önemli Test: İki Kullanıcıyla Karşılaştırma

IDOR'u doğrulamanın en temiz yollarından biri iki farklı yetkili kullanıcı kullanmaktır.

Örneğin:

User A → kendi hesabı
User B → başka hesap

User A'nın oluşturduğu bir kaynağın identifier'ını biliyoruz:

order_id = 500

User A:

GET /api/orders/500

gönderdiğinde siparişini görüyor.

Daha sonra aynı authenticated session ile aynı kaynak istenir:

GET /api/orders/500

Ancak bu kez User B'nin oturumuyla.

Beklenen davranış:

403 Forbidden

veya uygun başka bir yetkisiz erişim davranışıdır.

Eğer User B de aynı kaynağın içeriğini alabiliyorsa:

User B
  ↓
Order 500
  ↓
User A'ya ait veri
  ↓
200 OK

çok güçlü bir IDOR bulgusu elde edilmiş olur.

Buradaki kritik nokta authentication'ın devam ediyor olmasıdır.

Saldırganın login olması problemi ortadan kaldırmaz.

Tam tersine IDOR'un önemli bir bölümü, normal ve authenticated bir kullanıcının başka bir kullanıcının kaynağına erişebilmesi şeklinde ortaya çıkar.

Horizontal ve Vertical Authorization

IDOR testlerinde iki farklı yetki ihlali özellikle önemlidir.

Horizontal Privilege Escalation

Aynı seviyedeki iki kullanıcı arasında yetki ihlalidir.

Örneğin:

User A
   ↓
kendi faturası
User B
   ↓
User A'nın faturasını okuyabiliyor

İki kullanıcı da normal kullanıcıdır.

Ancak biri diğerinin kaynağına erişebilmektedir.

Bu horizontal authorization bypass olarak düşünülebilir.

Vertical Privilege Escalation

Bu kez farklı yetki seviyeleri arasında erişim gerçekleşir.

Örneğin:

Normal User
     ↓
Admin endpoint

Normal kullanıcının:

GET /admin/users

endpoint'ine erişebilmesi veya admin'e özel bir işlem yapabilmesi vertical privilege escalation problemidir.

Bu her zaman klasik IDOR şeklinde ortaya çıkmaz.

Örneğin:

POST /api/users/42/delete

endpoint'i bir object reference içeriyorsa hem IDOR hem de vertical authorization problemi birlikte bulunabilir.

Bu yüzden IDOR testi yalnızca "ID'yi değiştir" yaklaşımından ibaret olmamalıdır.

Sadece GET İsteklerini Test Etmemek

IDOR denildiğinde çoğu kişinin aklına:

GET /users/123

geliyor.

Fakat kaynaklara erişim yalnızca okumak değildir.

Şunlar da test edilmelidir:

GET     → Okuma
POST    → Oluşturma
PUT     → Güncelleme
PATCH   → Değiştirme
DELETE  → Silme

Örneğin kullanıcı kendi profilini güncelliyor:

PATCH /api/users/125

Request body:

{
  "email": "new@example.com"
}

Sunucu sadece oturum açmış kullanıcının request göndermesine bakıyor ve URL'deki 125 değerinin gerçekten o kullanıcıya ait olduğunu doğrulamıyorsa, başka bir kullanıcının hesabı değiştirilebilir.

Bu durumda veri sızdırmanın ötesinde yetkisiz veri değiştirme söz konusu olur.

DELETE endpoint'leri ise özellikle önemlidir.

Bir kullanıcının başka bir kullanıcının kaynağını silebilmesi, yalnızca gizlilik değil bütünlük açısından da ciddi bir problemdir.

IDOR Sadece Sayısal ID ile Olmaz

IDOR kelimesindeki "ID" bazen yanlış anlaşılabiliyor.

Identifier'ın:

123
124
125

şeklinde olması şart değildir.

Uygulama UUID kullanabilir:

550e8400-e29b-41d4-a716-446655440000

Bu durumda identifier tahmin edilmesi daha zor hale gelir.

Ancak UUID'yi bilen bir kullanıcı yine yetkisiz kaynağa erişebiliyorsa problem devam eder.

Örneğin:

GET /api/invoices/550e8400-e29b-41d4-a716-446655440000

isteğini başka bir kullanıcı gönderebiliyor ve sunucu faturayı döndürüyorsa, UUID kullanılması authorization problemini çözmemiştir.

Bu nedenle:

Tahmin edilemez ID ≠ Authorization

UUID, identifier enumeration riskini azaltabilir.

Fakat erişim kontrolünün yerini tutmaz.

"ID'yi Tahmin Edemiyorum" Neden Yeterli Değil?

Bu konu IDOR testlerinde özellikle önemli.

Bir uygulamada:

/order/100
/order/101
/order/102

yerine:

/order/9f8c2...

kullanılması saldırganın kaynakları sırayla keşfetmesini zorlaştırabilir.

Fakat güvenlik mekanizması şu olmamalıdır:

"ID'yi tahmin edemezse erişemez."

Güvenlik mekanizması şu olmalıdır:

"ID'yi bilse bile yetkisi yoksa erişemez."

Bu iki yaklaşım arasında büyük fark vardır.

IDOR'da Dosyalar da Unutulmamalı

IDOR yalnızca JSON response'larında aranmaz.

Dosya sistemleri de hedef olabilir.

Örneğin:

GET /download/7812

endpoint'i kullanıcının kendi PDF dosyasını indiriyor olabilir.

Başka bir kullanıcının dosyasının identifier'ı bilindiğinde:

GET /download/7813

isteği de başarılı oluyorsa burada IDOR bulunabilir.

Daha tehlikeli senaryolarda dosyalar:

  • Kimlik belgeleri
  • Faturalar
  • CV'ler
  • Özel fotoğraflar
  • Şirket dokümanları
  • Raporlar

olabilir.

Bu yüzden dosya indirme ve görüntüleme endpoint'leri authorization açısından ayrıca incelenmelidir.

API'lerde IDOR ve BOLA

Modern API güvenliğinde IDOR ile ilişkili çok önemli bir kavram daha var:

BOLA — Broken Object Level Authorization

Özellikle REST API'lerinde object-level authorization eksiklikleri önemli bir güvenlik problemi oluşturur.

Örneğin:

GET /api/orders/123

endpoint'inde 123 bir object identifier'dır.

Sunucunun yalnızca:

"Bu kullanıcı authenticated mı?"

diye bakması yeterli değildir.

Şunu da kontrol etmelidir:

"Bu kullanıcı 123 numaralı order üzerinde işlem yapabilir mi?"

OWASP API Security bağlamında bu problem BOLA olarak ele alınır.

Dolayısıyla modern API testlerinde IDOR mantığını yalnızca HTML sayfalarında değil, API endpoint'lerinde de düşünmek gerekir.

GraphQL'de de Aynı Problem Olabilir

REST API dışında GraphQL kullanan uygulamalarda da benzer authorization problemleri görülebilir.

Örneğin:

query {
  order(id: "123") {
    id
    total
    address
  }
}

Burada id bir object reference'tır.

Uygulama:

Kullanıcı authenticated mı?

kontrolünü yapıp:

Bu order bu kullanıcıya ait mi?

kontrolünü yapmıyorsa aynı authorization problemi GraphQL üzerinden de ortaya çıkabilir.

Bu yüzden kullanılan teknoloji değişse bile temel soru değişmez:

İstenen object üzerinde bu kullanıcının yetkisi var mı?

IDOR ile Mass Assignment Aynı Şey Değil

Bu iki zafiyet bazen birbirine karıştırılabiliyor.

IDOR'da temel problem genellikle:

Yanlış kaynağa erişim

iken Mass Assignment'ta problem:

Kullanıcının değiştirmemesi gereken alanları değiştirebilmesi

olabilir.

Örneğin:

{
  "username": "sena",
  "role": "admin"
}

gönderildiğinde backend role alanını da kabul ediyorsa bu Mass Assignment problemi olabilir.

Ancak:

PATCH /api/users/42

isteğiyle başka bir kullanıcının kaydının değiştirilmesi authorization kontrolü eksikliğine işaret edebilir.

İki problem aynı endpoint'te birlikte de bulunabilir.

Bu ayrımı yapmak önemlidir çünkü çözüm yöntemleri tamamen aynı değildir.

IDOR Tespitinde Burp Suite ile Çalışmak

IDOR testlerinde Burp Suite'in en önemli avantajlarından biri request'leri karşılaştırmayı kolaylaştırmasıdır.

Örneğin önce normal request'i yakalarız:

GET /api/orders/500 HTTP/1.1
Cookie: session=...

Daha sonra identifier değiştirilir:

GET /api/orders/501 HTTP/1.1
Cookie: session=...

Fakat yalnızca response'un 200 OK olması yeterli değildir.

Response içeriğine bakmak gerekir.

Örneğin:

{
  "id": 501,
  "customer": "other-user",
  "total": 4200
}

gibi bir response, kullanıcının başka bir kaynağa erişebildiğini gösterebilir.

Daha doğru bir test ise iki hesap arasında karşılaştırma yapmaktır:

User A → Resource A → başarılı
User B → Resource A → ?

Burada beklenen:

403 Forbidden

veya uygulamanın tasarımına uygun başka bir erişim reddidir.

Eğer User B resource A'nın içeriğini alabiliyorsa authorization bypass doğrulanmış olur.

Status Code Tek Başına Yeterli Değildir

IDOR testlerinde sık yapılan hatalardan biri sadece HTTP status code'a bakmaktır.

Örneğin:

200 OK

genellikle başarılı bir isteği gösterir.

Ama bazı uygulamalar yetkisiz durumda da:

200 OK

döndürebilir.

Response body içerisinde:

{
  "error": "not authorized"
}

bulunabilir.

Tam tersine bazı endpoint'ler:

404 Not Found

kullanarak kaynağın varlığını gizleyebilir.

Dolayısıyla test sırasında:

  • Status code
  • Response body
  • Response length
  • Redirect
  • Error mesajları
  • Header'lar
  • Dönen object'in sahibi

birlikte değerlendirilmelidir.

IDOR'da Enumeration da Önemli

Tahmin edilebilir identifier'lar ayrı bir güvenlik problemi oluşturabilir.

Örneğin:

1001
1002
1003
1004

şeklinde artan ID'ler kullanılıyorsa kaynakların varlığını keşfetmek kolaylaşabilir.

Burada iki farklı problemi ayırmak gerekir:

Enumeration:

"Başka kaynakların identifier'larını keşfedebiliyorum."

IDOR:

"Keşfettiğim identifier ile yetkim olmayan kaynağa erişebiliyorum."

Enumeration tek başına her zaman IDOR değildir.

Ancak enumeration ile IDOR birleştiğinde saldırı yüzeyi ciddi şekilde genişleyebilir.

IDOR'un Etkisi Nasıl Değerlendirilir?

Her IDOR aynı seviyede değildir.

Örneğin başka bir kullanıcının herkese açık olmayan:

profil fotoğrafını

görebilmek ile:

kimlik belgesini
faturasını
adresini
özel mesajlarını

görebilmek aynı etkiye sahip değildir.

Bu nedenle güvenlik raporunda yalnızca:

"IDOR var."

demek yeterli değildir.

Şunlar değerlendirilmelidir:

  • Hangi kaynak erişilebilir?
  • Kaynak başka kullanıcıya mı ait?
  • Hassas veri içeriyor mu?
  • Sadece okunabiliyor mu?
  • Değiştirilebiliyor mu?
  • Silinebiliyor mu?
  • Kaç kullanıcı etkilenebilir?
  • Multi-tenant bir yapı varsa başka şirketlerin verilerine erişilebilir mi?

Özellikle tenant izolasyonunun bozulması çok ciddi sonuçlar doğurabilir.

Örneğin:

Company A User
      ↓
Company B Invoice

gibi bir erişim, yalnızca kullanıcılar arası değil tenant'lar arası authorization bypass anlamına gelir.

Geliştirici Tarafında IDOR Nasıl Oluşuyor?

En yaygın problem, geliştiricinin yalnızca resource ID üzerinden sorgu yapmasıdır.

Örneğin:

const order = await db.query(
    "SELECT * FROM orders WHERE id = ?",
    [req.params.id]
);

Burada SQL Injection açısından parameterized query kullanılmış olması iyi bir şeydir.

Ancak IDOR açısından hâlâ problem olabilir.

Çünkü sorgu yalnızca:

id = ?

kontrol ediyor.

Kullanıcının kim olduğu sorguya dahil edilmemiş.

Daha doğru authorization mantığında sorgu veya sonrasındaki kontrol resource ownership bilgisini de dikkate almalıdır.

Örneğin:

const order = await db.query(
    "SELECT * FROM orders WHERE id = ? AND user_id = ?",
    [req.params.id, req.user.id]
);

Burada hem kaynak hem de kullanıcının ilişkisi kontrol edilir.

Fakat bu örnek her sistem için tek doğru çözüm değildir. Admin kullanıcıları, ekip erişimleri, paylaşılmış kaynaklar ve rol tabanlı yetkiler varsa authorization mantığının merkezi bir politika üzerinden yönetilmesi daha doğru olabilir.

Authorization Kontrolünü Frontend'e Bırakmamak

Bir başka yaygın hata frontend'deki kontrolleri güvenlik mekanizması olarak görmektir.

Örneğin frontend:

if (user.role === "admin") {
    showDeleteButton();
}

diyebilir.

Ama saldırgan frontend'deki butonu görmese bile request'i manuel olarak gönderebilir:

DELETE /api/users/42

Bu nedenle:

Frontend'deki butonun gizlenmesi authorization değildir.

Gerçek kontrol backend'de yapılmalıdır.

Sunucu gelen her kritik istekte kullanıcının yetkisini doğrulamalıdır.

IDOR'dan Korunmanın Temel Kuralları

IDOR'a karşı en önemli savunma tek bir teknikten oluşmaz.

1. Authorization kontrolünü server-side yap

Her resource erişiminde:

Bu kullanıcı bu kaynağa erişebilir mi?

sorusu backend tarafından cevaplanmalıdır.

2. Authentication'ı authorization yerine kullanma

Kullanıcının login olması:

Bu kullanıcı her kaynağa erişebilir.

anlamına gelmez.

3. UUID kullanmak tek başına çözüm değildir

Tahmin edilmesi zor identifier kullanmak faydalı olabilir ancak authorization kontrolünün yerini tutmaz.

4. Tüm HTTP metodlarını kontrol et

Sadece GET değil:

POST
PUT
PATCH
DELETE

istekleri de authorization açısından değerlendirilmelidir.

5. Dosya endpoint'lerini unutma

Download ve file access endpoint'leri de kaynak erişimidir.

6. Merkezi authorization politikaları kullan

Authorization mantığını uygulamanın farklı yerlerinde tekrar tekrar yazmak yerine mümkün olduğunca merkezi ve tutarlı hale getirmek hataları azaltır.

IDOR Testi İçin Kısa Bir Metodoloji

Laboratuvarlarda veya yetkili güvenlik testlerinde IDOR araştırırken izlediğim mantık şu şekilde özetlenebilir:

1. Uygulamaya login ol
        ↓
2. Kullanıcının erişebildiği kaynakları belirle
        ↓
3. Resource identifier'larını bul
        ↓
4. Aynı request'i farklı identifier ile dene
        ↓
5. Response'ları karşılaştır
        ↓
6. İkinci bir kullanıcıyla tekrar test et
        ↓
7. Okuma / değiştirme / silme işlemlerini kontrol et
        ↓
8. Authorization bypass'ı doğrula
        ↓
9. Etki alanını belirle
        ↓
10. Bulguyu raporla

Burada özellikle 6. adım önemli.

Çünkü bir ID'nin değiştirilebilmesi tek başına IDOR olduğunu göstermeyebilir.

Asıl soru:

Başka bir kullanıcının kaynağına erişilebiliyor mu?

Sonuç

IDOR ilk bakışta oldukça basit bir zafiyet gibi görünüyor.

Bir URL'deki:

123 → 124

değişikliği kadar basit bir test bile ciddi bir güvenlik açığını ortaya çıkarabilir.

Fakat IDOR'un arkasındaki asıl problem URL'deki sayı değildir.

Problem, uygulamanın:

Kimlik doğrulama
      ↓
Kaynak erişimi
      ↓
Yetki kontrolü

zincirinde kaynak seviyesindeki authorization kontrolünü doğru yapmamasıdır.

Bu nedenle IDOR test ederken yalnızca "ID değiştir ve bak" yaklaşımı yeterli değildir.

Uygulamanın kaynak modelini anlamak, farklı kullanıcılarla karşılaştırma yapmak, farklı HTTP metodlarını test etmek, API ve dosya endpoint'lerini incelemek ve en önemlisi authentication ile authorization arasındaki farkı doğru değerlendirmek gerekir.

SQL Injection'da temel soru:

"Kullanıcı girdisi SQL sorgusunun yapısını değiştirebiliyor mu?"

iken IDOR'da temel soru:

"Kullanıcı bu kaynağın sahibi veya yetkilisi olmadığı halde sunucu bu kaynağa erişmesine izin veriyor mu?"

Bu iki sorunun birbirinden tamamen farklı olması, web güvenliği testlerinde zafiyetin türünü doğru teşhis etmenin neden önemli olduğunu gösteriyor.