API Güvenliği: 10 Hata ve Güvenli API Geliştirme Yöntemleri

Modern yazılımların büyük bölümü API'ler üzerinden iletişim kuruyor. Web uygulamaları, mobil uygulamalar, ERP sistemleri, ödeme altyapıları, IoT cihazları ve mikroservisler farklı sistemler arasında veri alışverişi yapmak için API kullanıyor. Bu nedenle API güvenliği artık yalnızca backend geliştiricilerin değil, bütün yazılım projelerinin temel güvenlik konularından biri haline geldi.

Bir API'nin çalışıyor olması onun güvenli olduğu anlamına gelmez. Endpoint doğru veriyi döndürebilir, Authentication sistemi sorunsuz çalışabilir ve uygulama bütün testlerden geçebilir. Buna rağmen yanlış Authorization kontrolleri, gereğinden fazla veri döndürülmesi veya rate limiting eksikliği ciddi güvenlik açıklarına neden olabilir.

Bu yazıda API geliştirirken en sık yapılan 10 güvenlik hatasını, bu hataların neden tehlikeli olduğunu ve daha güvenli API tasarlamak için uygulanabilecek temel yöntemleri inceleyeceğiz.

API Güvenliği Nedir?

API güvenliği, bir API üzerinden erişilebilen verilerin ve işlemlerin yetkisiz kullanıcılardan, kötü amaçlı isteklerden ve yanlış kullanımdan korunmasını sağlayan yöntemlerin bütünüdür.

Güvenli bir API yalnızca kullanıcının kimliğini doğrulamaz. Kullanıcının hangi işlemleri gerçekleştirebileceğini, hangi verilere erişebileceğini, ne sıklıkta istek gönderebileceğini ve gönderilen verilerin geçerli olup olmadığını da kontrol eder.

• Authentication
• Authorization
• Input validation
• Rate limiting
• Encryption
• Logging ve monitoring
• Secret management
• Güvenli hata yönetimi

Bunlardan yalnızca birinin doğru uygulanması yeterli değildir. API güvenliği birden fazla güvenlik katmanının birlikte çalışmasıyla sağlanır.

1. Authentication ile Authorization'ı Aynı Şey Sanmak

API güvenliğinde yapılan en kritik hatalardan biri kullanıcının sisteme giriş yapmış olmasını bütün endpoint'lere erişebilmesi için yeterli kabul etmektir.

Authentication kullanıcının kim olduğunu doğrular. Authorization ise bu kullanıcının hangi işlemleri gerçekleştirebileceğini belirler.

Örneğin aşağıdaki endpoint yalnızca Authentication kontrolüne sahip olabilir.

GET /api/orders/1250

Kullanıcı sisteme giriş yapmış olsa bile 1250 numaralı siparişin kendisine ait olup olmadığı ayrıca kontrol edilmelidir. Aksi halde kullanıcı URL içerisindeki ID değerini değiştirerek başka kullanıcılara ait kayıtları görüntülemeyi deneyebilir.

Bu nedenle her kritik endpoint için iki ayrı soru sorulmalıdır: Kullanıcının kimliği doğrulandı mı ve bu kullanıcının bu kaynağa erişme yetkisi var mı?

2. Object-Level Authorization Kontrolü Yapmamak

Bir kullanıcının belirli bir endpoint'e erişme yetkisine sahip olması, endpoint üzerinden erişilebilen bütün nesnelere erişebileceği anlamına gelmez.

Örneğin bir müşteri kendi profilini aşağıdaki endpoint üzerinden görüntülüyor olabilir.

GET /api/users/105

Kullanıcı URL'yi değiştirerek aşağıdaki isteği gönderdiğinde başka bir kullanıcının bilgilerini görebiliyorsa ciddi bir erişim kontrolü problemi bulunmaktadır.

GET /api/users/106

Bu tür problemler doğrudan nesne referanslarının güvenli olmayan biçimde kullanılmasına ve nesne seviyesinde yetkilendirme eksikliklerine dayanabilir.

UUID kullanmak veya ID değerlerini tahmin edilmesi zor hale getirmek faydalı olabilir ancak Authorization kontrolünün yerine geçmez. Sunucu her istekte kullanıcının ilgili nesneye erişme hakkını doğrulamalıdır.

Laravel'de Kaynak Sahipliği Kontrolü

Örneğin Laravel uygulamasında yalnızca ID üzerinden kayıt getirmek yerine kullanıcının sahipliği de kontrol edilebilir.

$order = Order::where('id', $id)
->where('user_id', auth()->id())
->firstOrFail();

return response()->json($order);

Daha büyük projelerde bu kuralların Policy veya merkezi Authorization mekanizmaları içerisinde yönetilmesi kod tekrarını azaltabilir ve erişim politikalarının daha tutarlı uygulanmasını sağlayabilir.

3. Kullanıcıdan Gelen Veriye Güvenmek

API'ye gönderilen hiçbir veri güvenilir kabul edilmemelidir. İstek resmi mobil uygulamadan veya şirketin kendi frontend uygulamasından geliyor gibi görünse bile kullanıcı HTTP isteğini değiştirebilir.

Örneğin frontend yalnızca name ve email alanlarını gönderiyor olabilir.

{
"name": "Aziz",
"email": "[example@example.com](mailto:example@example.com)"
}

Ancak kötü niyetli bir kullanıcı isteği manuel olarak değiştirerek sisteme farklı alanlar göndermeyi deneyebilir.

{
"name": "Aziz",
"email": "[example@example.com](mailto:example@example.com)",
"role": "admin"
}

Backend gelen JSON içerisinde role bulunduğu için bunu doğrudan veritabanına kaydediyorsa kullanıcı kendisine yetki kazandırabilir.

Mass Assignment Riskleri

Kullanıcıdan gelen bütün request verisinin kontrol edilmeden modele aktarılması Mass Assignment problemlerine neden olabilir.

User::create($request->all());

Daha güvenli yaklaşım yalnızca beklenen ve doğrulanmış alanların işlenmesidir.

$data = $request->validate([
'name' => ['required', 'string', 'max:255'],
'email' => ['required', 'email'],
]);

User::create($data);

Buradaki temel prensip basittir: Frontend'in hangi alanları gönderdiğine değil, backend'in hangi alanları kabul ettiğine güvenilmelidir.

4. Rate Limiting Kullanmamak

Bir API endpoint'inin sınırsız sayıda çağrılabilmesi hem güvenlik hem de performans açısından risk oluşturabilir.

Özellikle login, parola sıfırlama, doğrulama kodu gönderme, arama ve yoğun veritabanı sorguları gerçekleştiren endpoint'ler kötüye kullanılabilir.

Rate limiting belirli bir kullanıcı, token, IP adresi veya başka bir tanımlayıcı için belirli süre içerisinde yapılabilecek istek sayısını sınırlar.

60 request / minute

Ancak bütün API için tek bir limit belirlemek her zaman yeterli değildir. Login endpoint'i ile ürün listeleme endpoint'inin riskleri aynı olmayabilir. Kritik endpoint'ler için daha sıkı ve bağlama uygun limitler uygulanabilir.

Rate Limiting Neye Karşı Koruma Sağlar?

• Brute-force giriş denemeleri.
• Doğrulama kodlarının kötüye kullanılması.
• API kaynaklarının aşırı tüketilmesi.
• Basit otomasyon saldırıları.
• Maliyet oluşturan endpoint'lerin kontrolsüz kullanılması.

Rate limiting tek başına DDoS koruması değildir ancak API savunmasının önemli katmanlarından biridir.

5. API Anahtarlarını ve Secret Bilgilerini Kaynak Koda Yazmak

API anahtarları, database parolaları, access token'ları ve diğer secret bilgiler doğrudan kaynak kod içerisinde tutulmamalıdır.

const apiKey = "my-secret-production-api-key";

Bu kod Git repository'sine gönderildiğinde secret değeri repository geçmişinde kalabilir. Dosyanın daha sonra değiştirilmesi veya anahtarın mevcut sürümden kaldırılması geçmiş commit'lerdeki değeri otomatik olarak ortadan kaldırmaz.

Secret bilgiler environment variable veya bu amaç için tasarlanmış secret management sistemleri üzerinden yönetilmelidir.

PAYMENT_API_KEY=********
DB_PASSWORD=********
JWT_SECRET=********

Bir secret yanlışlıkla açığa çıktıysa yalnızca dosyadan silmek yeterli değildir. İlgili anahtarın iptal edilmesi veya değiştirilmesi de gerekebilir.

Frontend İçerisinde Secret Saklanabilir mi?

Tarayıcıya veya son kullanıcı cihazına gönderilen bir değer gerçek anlamda gizli kabul edilmemelidir. Frontend JavaScript paketlerinin içerisindeki bilgiler kullanıcı tarafından incelenebilir.

Bu nedenle yalnızca sunucunun bilmesi gereken API secret'ları frontend koduna yerleştirilmemelidir. Hassas üçüncü taraf işlemleri gerektiğinde backend üzerinden gerçekleştirilmelidir.

6. Gereğinden Fazla Veri Döndürmek

API endpoint'lerinin veritabanındaki bütün alanları istemciye göndermesi sık yapılan güvenlik ve veri minimizasyonu hatalarından biridir.

return User::findOrFail($id);

User modeli içerisinde istemcinin ihtiyaç duymadığı alanlar bulunabilir. Uygulama yalnızca kullanıcının adını ve profil fotoğrafını göstermesine rağmen API çok daha fazla veri döndürüyor olabilir.

• E-posta adresi.
• Telefon numarası.
• İç sistem ID'leri.
• Rol bilgileri.
• İç operasyon alanları.
• Timestamp bilgileri.

İstemci hangi verilere gerçekten ihtiyaç duyuyorsa yalnızca o alanların döndürülmesi daha güvenli bir tasarımdır.

{
"id": 42,
"name": "Aziz",
"avatar": "/images/avatar.webp"
}

Parola Hash'i Döndürmek Güvenli midir?

Hayır. Parola hash'i doğrudan parola olmasa bile istemcinin buna ihtiyacı yoktur ve API cevabına dahil edilmemelidir. Aynı prensip reset token'ları ve diğer hassas dahili alanlar için de geçerlidir.

Güvenlik açısından "kullanıcı zaten giriş yaptı" yaklaşımı yerine veri minimizasyonu uygulanmalıdır.

7. Hatalı Token ve Session Yönetimi

API Authentication sistemlerinde token kullanmak tek başına güvenlik sağlamaz. Token'ın nasıl oluşturulduğu, saklandığı, doğrulandığı ve iptal edildiği de önemlidir.

Uzun süre geçerli access token'lar saldırganın token'ı ele geçirmesi durumunda riski büyütebilir. Uygulamanın mimarisine göre kısa ömürlü access token ve kontrollü yenileme mekanizmaları değerlendirilebilir.

• Token'ın geçerlilik süresi olmalıdır.
• Token doğrulaması güvenli yapılmalıdır.
• Logout ve gerektiğinde token iptal mekanizmaları düşünülmelidir.
• Refresh token kullanılıyorsa ayrıca korunmalıdır.
• Token'lar loglara yazılmamalıdır.
• URL query parametresi içerisinde hassas token taşımaktan kaçınılmalıdır.

JWT Kullanmak API'yi Otomatik Olarak Güvenli Yapar mı?

Hayır. JWT yalnızca belirli problemlerin çözümünde kullanılan bir token formatıdır. JWT kullanılması Authorization açıklarını, veri sızıntılarını veya yanlış yapılandırılmış endpoint'leri otomatik olarak engellemez.

JWT imzasının doğru doğrulanması, token'ın süresinin kontrol edilmesi ve uygulamanın gerektirdiği claim kontrollerinin yapılması gerekir. Bunun yanında kullanıcı ilgili işlemi gerçekleştirmeye yetkili mi sorusu ayrıca değerlendirilmelidir.

8. HTTPS Kullanmamak

API trafiğinin HTTP üzerinden şifrelenmeden gönderilmesi, ağ üzerinden geçen bilgilerin korunmasını ciddi şekilde zayıflatır.

API istekleri kullanıcı bilgileri, Authentication token'ları, kişisel veriler veya ödeme sistemleriyle ilgili bilgiler içerebilir. Bu nedenle production API trafiğinde TLS üzerinden HTTPS kullanılması temel gereksinimlerden biridir.

[https://api.example.com/v1/orders](https://api.example.com/v1/orders)

HTTPS kullanılması uygulamanın bütün güvenlik problemlerini çözmez. Ancak istemci ile sunucu arasındaki verinin aktarım sırasında korunmasının temel parçalarından biridir.

9. Hata Mesajlarında Fazla Bilgi Vermek

Development ortamında detaylı hata mesajları geliştirici için son derece faydalıdır. Ancak aynı hata detaylarının production ortamında kullanıcıya gönderilmesi sistem hakkında gereksiz teknik bilgi açığa çıkarabilir.

SQLSTATE[42S02]: Base table or view not found...
Database: production_database
Table: customer_orders
File: /var/www/app/Services/OrderService.php
Line: 184

Bu tür cevaplar saldırgana kullanılan veritabanı, tablo isimleri, dosya yolları veya uygulamanın iç mimarisi hakkında bilgi verebilir.

Kullanıcıya kontrollü ve genel bir hata mesajı döndürülürken ayrıntılı teknik bilgiler güvenli sunucu loglarında tutulabilir.

{
"error": "İşlem gerçekleştirilemedi."
}

Stack Trace Production Ortamında Gösterilmeli mi?

Genellikle hayır. Stack trace geliştirici için değerlidir ancak son kullanıcıya gösterilmesi gereksiz teknik bilgi sızıntısına neden olabilir. Production ortamında debug özellikleri kapatılmalı ve hata cevapları kontrollü biçimde oluşturulmalıdır.

10. Logging ve Monitoring Yapmamak

API'nin güvenli olması yalnızca saldırıyı engellemek değildir. Şüpheli davranışların fark edilebilmesi de gerekir.

Hiçbir güvenlik sistemi bütün saldırıları kesin olarak engelleyemez. Bu nedenle uygulamanın olağan dışı davranışları tespit edebilmesi önemlidir.

• Çok sayıda başarısız login denemesi.
• Kısa sürede binlerce API isteği.
• Sürekli 401 veya 403 cevabı oluşturan istemciler.
• Beklenmeyen yönetici işlemleri.
• Ani trafik artışları.
• Şüpheli token kullanımları.
• Kritik verilerin toplu olarak çekilmesi.

Bu olayların loglanması ve gerektiğinde alarm mekanizmalarıyla takip edilmesi saldırıların veya hatalı sistem davranışlarının daha erken fark edilmesini sağlayabilir.

Loglara Hassas Veri Yazmayın

Logging güvenlik için gereklidir ancak yanlış logging yaklaşımı kendi başına veri sızıntısına dönüşebilir.

Aşağıdaki bilgilerin loglanması konusunda özellikle dikkatli olunmalıdır.

• Parolalar.
• Access token'lar.
• Refresh token'lar.
• API secret'ları.
• Ödeme bilgileri.
• Gereksiz kişisel veriler.

Log sistemi de uygulamanın diğer veri kaynakları gibi korunması gereken bir sistemdir.

API Güvenliğinde Sık Görülen Ek Hatalar

Yukarıdaki 10 temel problemin dışında API güvenliğini etkileyebilecek başka tasarım hataları da bulunmaktadır.

CORS Ayarlarını Gereğinden Fazla Açmak

CORS tarayıcıların farklı origin'ler arasındaki isteklere nasıl izin vereceğini belirleyen bir mekanizmadır. Gereksiz derecede geniş CORS politikaları uygulamanın ihtiyaç duyduğundan daha fazla kaynağa tarayıcı üzerinden erişim imkanı sağlayabilir.

CORS'un bir Authentication veya Authorization sistemi olmadığı unutulmamalıdır. API endpoint'lerinin güvenliği yalnızca CORS ayarlarına bırakılmamalıdır.

HTTP Method Kontrollerini Önemsememek

API tasarımında GET, POST, PUT, PATCH ve DELETE gibi HTTP method'larının amaçlarına uygun kullanılması hem anlaşılabilirlik hem de güvenlik politikalarının uygulanması açısından önemlidir.

Özellikle veri değiştiren işlemlerin yanlışlıkla GET endpoint'leri üzerinden yapılması istenmeyen davranışlara neden olabilir.

Pagination Kullanmamak

Binlerce veya milyonlarca kaydın tek API isteğiyle döndürülebilmesi performans problemi oluşturmanın yanında kötüye kullanımı da kolaylaştırabilir.

GET /api/orders?page=1&per_page=50

Sunucu, istemcinin per_page değerini sınırsız belirlemesine de izin vermemelidir. Örneğin maksimum 100 kayıt gibi uygulamaya uygun üst sınırlar tanımlanabilir.

Dosya Yükleme Endpoint'lerini Kontrolsüz Bırakmak

Dosya yükleme endpoint'leri API'nin en dikkatli tasarlanması gereken alanlarından biridir. Dosyanın uzantısına güvenmek tek başına yeterli değildir. Dosya tipi, boyutu, saklama konumu ve erişim yöntemi değerlendirilmelidir.

Kullanıcı tarafından yüklenen dosyaların doğrudan çalıştırılabilir hale gelmesi özellikle ciddi güvenlik sorunlarına neden olabilir.

API Versiyonlamasını Düşünmemek

API geliştikçe eski istemciler ile yeni backend sürümleri arasında uyumsuzluk oluşabilir. Versiyonlama güvenlik açığını doğrudan engellemez ancak eski ve güvenli olmayan endpoint'lerin kontrollü biçimde kullanımdan kaldırılmasını kolaylaştırabilir.

/api/v1/orders
/api/v2/orders

API Anahtarı ile Kullanıcı Authentication Aynı Şey midir?

Her zaman değildir. API key çoğu sistemde uygulamayı, servisi veya entegrasyonu tanımlamak için kullanılır. Son kullanıcı kimliğinin doğrulanması için farklı Authentication mekanizmaları gerekebilir.

API key kullanılması kullanıcı seviyesindeki Authorization kontrollerini ortadan kaldırmaz. Özellikle birden fazla kullanıcının verisine erişen sistemlerde her işlemin hangi kullanıcı veya servis adına gerçekleştirildiğinin bilinmesi önemlidir.

API Key URL İçerisinde Gönderilmeli mi?

Hassas token ve anahtarların query string içerisinde taşınmasından mümkün olduğunca kaçınılmalıdır. URL'ler browser geçmişi, proxy kayıtları, analytics sistemleri veya sunucu logları gibi farklı noktalarda kaydedilebilir.

/api/orders?api_key=SECRET_KEY

Kullanılan Authentication yönteminin gerektirdiği güvenli header veya diğer standart mekanizmalar tercih edilmelidir.

API Endpoint'lerini Gizlemek Güvenlik Sağlar mı?

Hayır. Endpoint adresinin kullanıcı tarafından bilinmemesi gerçek bir güvenlik mekanizması değildir.

/api/internal/super-secret-admin-action

Adres ne kadar karmaşık olursa olsun endpoint'in uygun Authentication ve Authorization kontrollerine sahip olması gerekir. Güvenlik, endpoint'in bulunamayacağı varsayımına dayanmamalıdır.

Frontend'de Butonu Gizlemek API'yi Korur mu?

Hayır. Bir kullanıcının Delete butonunu görememesi DELETE isteğini doğrudan API'ye gönderemeyeceği anlamına gelmez.

Frontend kontrolleri kullanıcı deneyimini düzenler. Gerçek güvenlik kontrolü backend tarafından gerçekleştirilmelidir.

API Güvenliğinde Input Validation

API'ye gönderilen verilerin tipi, uzunluğu, formatı ve izin verilen değerleri backend tarafından doğrulanmalıdır.

{
"quantity": -500000,
"discount": 999999,
"role": "admin"
}

JSON formatının teknik olarak geçerli olması verinin iş mantığı açısından geçerli olduğu anlamına gelmez.

Örneğin quantity integer olabilir ancak negatif olmaması gerekebilir. Discount sayısal olabilir ancak kullanıcının bu değeri belirleme yetkisi bulunmayabilir.

Validation ile Authorization Arasındaki Fark

Validation verinin geçerli olup olmadığını kontrol eder. Authorization ise kullanıcının bu veriyi değiştirmeye yetkili olup olmadığını kontrol eder.

Bir değer teknik olarak tamamen geçerli olduğu halde kullanıcının onu değiştirme yetkisi olmayabilir. Bu nedenle iki kontrol birbirinin yerine kullanılmamalıdır.

SQL Injection ve API Güvenliği

Kullanıcıdan alınan verinin SQL sorgusuna kontrolsüz şekilde eklenmesi SQL Injection riskine neden olabilir.

Modern framework'lerin ORM ve parameter binding mekanizmaları bu riskin azaltılmasına yardımcı olur. Ancak geliştiricinin raw query oluşturduğu noktalarda kullanıcı girdilerini doğrudan sorgu metnine birleştirmemesi gerekir.

DB::select(
'SELECT * FROM users WHERE email = ?',
[$email]
);

Burada temel yaklaşım sorgu yapısı ile kullanıcı verisini birbirinden ayırmaktır.

API Güvenliğinde Database Yetkileri

Uygulamanın database kullanıcısına ihtiyaç duymadığı yetkilerin verilmemesi savunmanın önemli katmanlarından biridir.

Bir API yalnızca belirli işlemleri gerçekleştiriyorsa database hesabının bütün veritabanı sunucusu üzerinde yönetici yetkisine sahip olması gerekmeyebilir.

Bu yaklaşım Least Privilege prensibinin veritabanı seviyesindeki uygulamalarından biridir.

Yapay Zeka ile API Geliştirirken Güvenlik

Yapay zeka kodlama araçlarının yaygınlaşması API geliştirmeyi önemli ölçüde hızlandırdı. Ancak yapay zekanın oluşturduğu endpoint'in çalışması güvenli olduğu anlamına gelmez.

Örneğin yapay zekaya "sipariş detaylarını döndüren endpoint oluştur" denildiğinde aşağıdaki gibi çalışan bir kod oluşturabilir.

public function show($id)
{
return Order::findOrFail($id);
}

Kod teknik olarak görevini yerine getirir. Ancak kullanıcının ilgili siparişe erişim yetkisi kontrol edilmiyorsa güvenlik problemi oluşabilir.

Bu nedenle yapay zekaya API kodu yazdırırken Authentication, Authorization, validation, rate limiting, hata yönetimi ve veri minimizasyonu gibi gereksinimler ayrıca belirtilmeli ve oluşturulan kod geliştirici tarafından incelenmelidir.

API Güvenliği İçin Kontrol Listesi

• Bütün kritik endpoint'lerde Authentication gereksinimini kontrol edin.
• Her kaynak için Authorization kontrolü yapın.
• Kullanıcıdan gelen bütün verileri doğrulayın.
• Mass Assignment risklerini kontrol edin.
• Rate limiting uygulayın.
• API secret'larını kaynak koddan uzak tutun.
• Frontend içerisinde gerçek secret saklamayın.
• API cevaplarında yalnızca gerekli verileri gönderin.
• Token sürelerini ve iptal mekanizmalarını yönetin.
• Production ortamında HTTPS kullanın.
• Detaylı hata mesajlarını son kullanıcıya göstermeyin.
• Şüpheli API aktivitelerini loglayın ve izleyin.
• Loglara parola ve token gibi hassas bilgiler yazmayın.
• CORS politikasını uygulamanın ihtiyacına göre sınırlandırın.
• Dosya yükleme endpoint'lerini ayrıca güvence altına alın.
• Database kullanıcılarına minimum gerekli yetkileri verin.
• Production debug modunu kapatın.
• API bağımlılıklarını ve framework sürümlerini güncel tutun.
• Authorization senaryolarını otomatik testlerle doğrulayın.
• Güvenlik kontrollerini yalnızca frontend'e bırakmayın.

Güvenli Bir API'nin Temel Mantığı

Bir API isteği geldiğinde güvenlik açısından yalnızca "endpoint çalışıyor mu?" sorusu sorulmamalıdır. İstek bir dizi kontrolden geçirilmelidir.

• İstek güvenli bağlantı üzerinden mi geliyor?
• Kullanıcının kimliği doğrulandı mı?
• Kullanıcı bu işlemi yapmaya yetkili mi?
• Kullanıcı bu spesifik kaynağa erişebilir mi?
• Gönderilen veri beklenen formatta mı?
• Gönderilen değerler iş kurallarına uygun mu?
• İstek kullanım limitleri içerisinde mi?
• Cevap gereğinden fazla bilgi içeriyor mu?
• İşlem gerektiği şekilde loglanıyor mu?

Bu kontroller güvenli API tasarımının temelini oluşturur.

Sonuç

API güvenliği yalnızca JWT eklemek, HTTPS kullanmak veya endpoint'leri Authentication middleware arkasına almak değildir. Güvenli bir API; kimlik doğrulama, yetkilendirme, veri doğrulama, rate limiting, secret yönetimi, güvenli hata cevapları, veri minimizasyonu ve izleme mekanizmalarının birlikte çalışmasıyla oluşturulur.

Özellikle Authorization eksiklikleri dikkatle ele alınmalıdır. Kullanıcının sisteme giriş yapmış olması, erişmeye çalıştığı bütün verilere yetkili olduğu anlamına gelmez. Her kritik kaynak ve işlem için erişim politikası sunucu tarafında doğrulanmalıdır.

Aynı şekilde istemciden gelen hiçbir veri güvenilir kabul edilmemeli, frontend güvenlik sınırı olarak görülmemeli ve API'nin yalnızca normal uygulama üzerinden kullanılacağı varsayılmamalıdır. Bir saldırgan API isteklerini doğrudan oluşturabilir ve uygulamanın göndermediği parametreleri göndermeyi deneyebilir.

API güvenliğinin temel prensibi güveni minimumda tutmak ve her kritik işlemi doğrulamaktır. Kullanıcı kim, hangi kaynağa erişmek istiyor, bu işlemi yapmaya yetkili mi, gönderdiği veri geçerli mi ve sistem bu isteği güvenli biçimde gerçekleştirebilir mi? Sağlam bir API mimarisi bu soruların tamamına cevap verebilmelidir.