Güvenlik

Bu konu, Angular'ın siteler arası komut dosyası çalıştırma saldırıları gibi yaygın web uygulama güvenlik açıkları ve saldırılarına karşı yerleşik korumaları açıklamaktadır. Kimlik doğrulama ve yetkilendirme gibi uygulama düzeyinde güvenliği kapsamaz.

Aşağıda açıklanan saldırılar ve azaltma yöntemleri hakkında daha fazla bilgi için Open Web Application Security Project (OWASP) Kılavuzu'na bakın.

En iyi uygulamalar

Angular uygulamanızın güvenli olmasını sağlamak için bazı en iyi uygulamalar şunlardır.

1. En son Angular kütüphane sürümleriyle güncel kalın - Angular kütüphaneleri düzenli olarak güncellenir ve bu güncellemeler önceki sürümlerde keşfedilen güvenlik açıklarını düzeltebilir. Güvenlikle ilgili güncellemeler için Angular değişiklik günlüğünü kontrol edin.
2. Angular kopyanızı değiştirmeyin - Özel, kişiselleştirilmiş Angular sürümleri mevcut sürümün gerisinde kalma eğilimindedir ve önemli güvenlik düzeltmeleri ve iyileştirmeler içermeyebilir. Bunun yerine, Angular iyileştirmelerinizi toplulukla paylaşın ve bir pull request yapın.
3. Belgelerde "Güvenlik Riski" olarak işaretlenmiş Angular API'lerinden kaçının - Daha fazla bilgi için bu sayfanın Güvenli değerlere güvenme bölümüne bakın.

Siteler arası komut dosyası çalıştırmayı (XSS) önleme

Siteler arası komut dosyası çalıştırma (XSS) saldırganların web sayfalarına kötü amaçlı kod enjekte etmesine olanak tanır. Bu tür kodlar daha sonra, örneğin kullanıcı ve giriş verilerini çalabilir veya kullanıcıyı taklit eden eylemler gerçekleştirebilir. Bu, web üzerindeki en yaygın saldırılardan biridir.

XSS saldırılarını engellemek için kötü amaçlı kodun Belge Nesne Modeli'ne (DOM) girmesini engellemeniz gerekir. Örneğin, saldırganlar sizi DOM'a bir <script> etiketi eklemeye kandırabilirse, web sitenizde rastgele kod çalıştırabilirler. Saldırı <script> etiketleriyle sınırlı değildir - DOM'daki birçok öğe ve özellik kod çalıştırmaya izin verir, örneğin <img alt="" onerror="..."> ve <a href="javascript:...">. Saldırgan kontrollü veriler DOM'a girerse, güvenlik açıkları bekleyin.

Angular'ın siteler arası komut dosyası çalıştırma güvenlik modeli

XSS hatalarını sistematik olarak engellemek için Angular, varsayılan olarak tüm değerleri güvenilmez olarak değerlendirir. Bir değer şablon bağlayıcı veya enterpolasyon yoluyla DOM'a eklendiğinde, Angular güvenilmez değerleri sterilize eder ve kaçırır. Bir değer Angular dışında zaten sterilize edilmişse ve güvenli kabul ediliyorsa, değeri güvenilir olarak işaretleyerek bunu Angular'a bildirin.

Render için kullanılacak değerlerin aksine, Angular şablonları varsayılan olarak güvenilir kabul edilir ve çalıştırılabilir kod olarak değerlendirilmelidir. Asla kullanıcı girişi ve şablon sözdizimini birleştirerek şablonlar oluşturmayın. Bunu yapmak, saldırganların uygulamanıza rastgele kod enjekte etmesine olanak tanır. Bu güvenlik açıklarını önlemek için üretim dağıtımlarında her zaman varsayılan Ahead-Of-Time (AOT) şablon derleyicisini kullanın.

İçerik güvenlik politikası ve Güvenilir Türler kullanımıyla ek bir koruma katmanı sağlanabilir. Bu web platform özellikleri, XSS sorunlarını önlemek için en etkili yer olan DOM düzeyinde çalışır. Burada diğer, daha düşük seviyeli API'ler kullanılarak atlanamaz. Bu nedenle, bu özelliklerden yararlanmanız kesinlikle teşvik edilir. Bunu yapmak için uygulama için içerik güvenlik politikasını yapılandırın ve güvenilir tür uygulamasını etkinleştirin.

Sterilizasyon ve güvenlik bağlamları

Sterilizasyon, güvenilmez bir değerin incelenmesi ve DOM'a eklenmesi güvenli olan bir değere dönüştürülmesidir. Birçok durumda, sterilizasyon bir değeri hiç değiştirmez. Sterilizasyon bağlama bağlıdır. Örneğin, CSS'de zararsız olan bir değer bir URL'de potansiyel olarak tehlikeli olabilir.

Angular aşağıdaki güvenlik bağlamlarını tanımlar:

Angular, HTML ve URL'ler için güvenilmez değerleri sterilize eder. Kaynak URL'lerini sterilize etmek mümkün değildir çünkü rastgele kod içerirler. Geliştirme modunda Angular, sterilizasyon sırasında bir değeri değiştirmek zorunda kaldığında konsola bir uyarı yazdırır.

Sterilizasyon örneği

Aşağıdaki şablon, htmlSnippet'in değerini bağlar. Bir kez bir öğenin içeriğine enterpolasyon yaparak ve bir kez bir öğenin innerHTML özelliğine bağlayarak:

<h3>Binding innerHTML</h3>
<p>Bound value:</p>
<p class="e2e-inner-html-interpolated">{{ htmlSnippet }}</p>
<p>Result of binding to innerHTML:</p>
<p class="e2e-inner-html-bound" [innerHTML]="htmlSnippet"></p>

Enterpolasyonlu içerik her zaman kaçırılır - HTML yorumlanmaz ve tarayıcı öğenin metin içeriğinde açılı parantezleri görüntüler.

HTML'in yorumlanması için, onu innerHTML gibi bir HTML özelliğine bağlayın. Bir saldırganın kontrol edebileceği bir değeri innerHTML'e bağlamanın normalde bir XSS güvenlik açığına neden olduğunu unutmayın. Örneğin, JavaScript aşağıdaki şekilde çalıştırılabilir:

export class InnerHtmlBindingComponent {
  // For example, a user/attacker-controlled value from a URL.
  htmlSnippet = 'Template <script>alert("0wned")</script> <b>Syntax</b>';
}

Angular değeri güvensiz olarak tanır ve otomatik olarak sterilize eder; script öğesini kaldırır ancak <b> öğesi gibi güvenli içeriği korur.

DOM API'lerinin doğrudan kullanımı ve açık sterilizasyon çağrıları

Güvenilir Türleri zorlamadığınız sürece, yerleşik tarayıcı DOM API'leri sizi güvenlik açıklarından otomatik olarak korumaz. Örneğin, document, ElementRef aracılığıyla kullanılabilir düğüm ve birçok üçüncü taraf API güvensiz yöntemler içerir. Aynı şekilde, DOM'u manipüle eden diğer kütüphanelerle etkileşime geçerseniz, muhtemelen Angular enterpolasyonlarıyla aynı otomatik sterilizasyona sahip olmayacaksınız. DOM ile doğrudan etkileşimden kaçının ve mümkün olduğunda Angular şablonlarını kullanın.

Bunun kaçınılmaz olduğu durumlar için yerleşik Angular sterilizasyon fonksiyonlarını kullanın. Güvenilmez değerleri DomSanitizer.sanitize yöntemi ve uygun SecurityContext ile sterilize edin. Bu fonksiyon ayrıca bypassSecurityTrust fonksiyonları kullanılarak güvenilir olarak işaretlenmiş değerleri de kabul eder ve aşağıda açıklandığı gibi bunları sterilize etmez.

Güvenli değerlere güvenme

Bazen uygulamaların gerçekten çalıştırılabilir kod içermesi, bir URL'den bir <iframe> görüntülemesi veya potansiyel olarak tehlikeli URL'ler oluşturması gerekir. Bu durumlarda otomatik sterilizasyonu önlemek için Angular'a bir değeri incelediğinizi, nasıl oluşturulduğunu kontrol ettiğinizi ve güvenli olduğundan emin olduğunuzu söyleyin. Dikkatli olun. Kötü amaçlı olabilecek bir değere güvenirseniz, uygulamanıza bir güvenlik açığı eklemiş olursunuz. Şüpheniz varsa, profesyonel bir güvenlik uzmanı bulun.

Bir değeri güvenilir olarak işaretlemek için DomSanitizer'ı enjekte edin ve aşağıdaki yöntemlerden birini çağırın:

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

Bir değerin güvenli olup olmadığının bağlama bağlı olduğunu unutmayın, bu nedenle değerinizin amaçlanan kullanımı için doğru bağlamı seçin. Aşağıdaki şablonun bir URL'yi javascript:alert(...) çağrısına bağlaması gerektiğini düşünün:

<h4>An untrusted URL:</h4>
<p><a class="e2e-dangerous-url" [href]="dangerousUrl">Click me</a></p>
<h4>A trusted URL:</h4>
<p><a class="e2e-trusted-url" [href]="trustedUrl">Click me</a></p>

Normalde Angular, URL'yi otomatik olarak sterilize eder, tehlikeli kodu devre dışı bırakır ve geliştirme modunda bu eylemi konsola kaydeder. Bunu önlemek için bypassSecurityTrustUrl çağrısını kullanarak URL değerini güvenilir bir URL olarak işaretleyin:

private sanitizer = inject(DomSanitizer);
  constructor() {
    // javascript: URLs are dangerous if attacker controlled.
    // Angular sanitizes them in data binding, but you can
    // explicitly tell Angular to trust this value:
    this.dangerousUrl = 'javascript:alert("Hi there")';
    this.trustedUrl = this.sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);

Kullanıcı girişini güvenilir bir değere dönüştürmeniz gerekiyorsa, bir bileşen yöntemi kullanın. Aşağıdaki şablon, kullanıcıların bir YouTube video kimliği girmesine ve ilgili videoyu bir <iframe> içinde yüklemesine olanak tanır. <iframe src> niteliği bir kaynak URL güvenlik bağlamıdır çünkü güvenilmez bir kaynak, şüphelenmeyen kullanıcıların çalıştırabileceği dosya indirmelerini gizlice yerleştirebilir. Bunu önlemek için güvenilir bir video URL'si oluşturmak için bileşen üzerinde bir yöntem çağırın; bu, Angular'ın <iframe src> bağlamasına izin vermesine neden olur:

<h4>Resource URL:</h4>
<p>Showing: {{ dangerousVideoUrl }}</p>
<p>Trusted:</p>
<iframe
  class="e2e-iframe-trusted-src"
  width="640"
  height="390"
  [src]="videoUrl"
  title="trusted video url"
></iframe>
<p>Untrusted:</p>
<iframe
  class="e2e-iframe-untrusted-src"
  width="640"
  height="390"
  [src]="dangerousVideoUrl"
  title="unTrusted video url"
></iframe>

updateVideoUrl(id: string) {
    // Appending an ID to a YouTube URL is safe.
    // Always make sure to construct SafeValue objects as
    // close as possible to the input data so
    // that it's easier to check if the value is safe.
    this.dangerousVideoUrl = 'https://www.youtube.com/embed/' + id;
    this.videoUrl = this.sanitizer.bypassSecurityTrustResourceUrl(this.dangerousVideoUrl);
  }

İçerik güvenlik politikası

İçerik Güvenlik Politikası (CSP), XSS'i önlemek için derinlemesine bir savunma tekniğidir. CSP'yi etkinleştirmek için web sunucunuzu uygun bir Content-Security-Policy HTTP başlığı döndürecek şekilde yapılandırın. İçerik güvenlik politikası hakkında daha fazla bilgiyi Google Developers web sitesindeki Web Fundamentals kılavuzunda bulabilirsiniz.

Yeni bir Angular uygulaması için gereken minimum politika şudur:

default-src 'self'; style-src 'self' 'nonce-randomNonceGoesHere'; script-src 'self' 'nonce-randomNonceGoesHere';

Angular uygulamanızı sunarken, sunucu her istek için HTTP başlığına rastgele oluşturulmuş bir nonce eklemelidir. Bu nonce'u Angular'a sağlamalısınız, böylece framework <style> öğelerini render edebilir. Angular için nonce'u aşağıdaki yollardan biriyle ayarlayabilirsiniz:

1. Çalışma alanı yapılandırmasında autoCsp seçeneğini true olarak ayarlayın.
2. Kök uygulama öğesinde ngCspNonce niteliğini <app ngCspNonce="randomNonceGoesHere"></app> olarak ayarlayın. Yanıtı oluştururken nonce'u hem başlığa hem de index.html'ye ekleyebilen sunucu tarafı şablonlamaya erişiminiz varsa bu yaklaşımı kullanın.
3. CSP_NONCE enjeksiyon token'ını kullanarak nonce'u sağlayın. Çalışma zamanında nonce'a erişiminiz varsa ve index.html'yi önbelleğe alabilmek istiyorsanız bu yaklaşımı kullanın.

import {bootstrapApplication, CSP_NONCE} from '@angular/core';
import {AppComponent} from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    {
      provide: CSP_NONCE,
      useValue: globalThis.myRandomNonceValue,
    },
  ],
});

Projenizde nonce oluşturamıyorsanız, CSP başlığının style-src bölümüne 'unsafe-inline' ekleyerek satır içi stillere izin verebilirsiniz.

Angular'ın düzgün çalışması için yalnızca bu ayarlar gereklidir. Projeniz büyüdükçe, uygulamanıza özgü ekstra özellikler için CSP ayarlarınızı genişletmeniz gerekebilir.

Güvenilir Türleri Zorlama

Uygulamalarınızı siteler arası komut dosyası çalıştırma saldırılarından korumaya yardımcı olmak için bir yol olarak Güvenilir Türler kullanmanız önerilir. Güvenilir Türler, daha güvenli kodlama uygulamalarını zorlayarak siteler arası komut dosyası çalıştırma saldırılarını önlemeye yardımcı olabilen bir web platform özelliğidir. Güvenilir Türler ayrıca uygulama kodunun denetimini basitleştirmeye de yardımcı olabilir.

Uygulamanız için Güvenilir Türleri zorlamak amacıyla, uygulamanızın web sunucusunu aşağıdaki Angular politikalarından biriyle HTTP başlıkları yayacak şekilde yapılandırmanız gerekir:

Güvenilir Türler için HTTP başlıklarını aşağıdaki konumlarda yapılandırmalısınız:

• Üretim sunma altyapısı
• Yerel geliştirme ve uçtan uca test için angular.json dosyasındaki headers özelliğini kullanarak Angular CLI (ng serve)
• Birim testi için karma.config.js dosyasındaki customHeaders özelliğini kullanarak Karma (ng test)

Aşağıda Güvenilir Türler ve Angular için özel olarak yapılandırılmış bir başlık örneği verilmiştir:

Content-Security-Policy: trusted-types angular; require-trusted-types-for 'script';

Angular'ın güvenliği atlayan DomSanitizer yöntemlerinden herhangi birini kullanan Güvenilir Türler ve Angular uygulamaları için özel olarak yapılandırılmış bir başlık örneği:

Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for
'script';

Aşağıda JIT kullanan Güvenilir Türler ve Angular uygulamaları için özel olarak yapılandırılmış bir başlık örneği verilmiştir:

Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for
'script';

Aşağıda modüllerin tembel yüklemesini kullanan Güvenilir Türler ve Angular uygulamaları için özel olarak yapılandırılmış bir başlık örneği verilmiştir:

Content-Security-Policy: trusted-types angular angular#bundler; require-trusted-types-for 'script';

AOT şablon derleyicisini kullanın

AOT şablon derleyicisi, şablon enjeksiyonu olarak adlandırılan tüm bir güvenlik açığı sınıfını önler ve uygulama performansını büyük ölçüde artırır. AOT şablon derleyicisi, Angular CLI uygulamaları tarafından kullanılan varsayılan derleyicidir ve tüm üretim dağıtımlarında kullanmalısınız.

AOT derleyicisine bir alternatif, çalışma zamanında tarayıcıda şablonları çalıştırılabilir şablon koduna derleyen JIT derleyicisidir. Angular şablon koduna güvenir, bu nedenle dinamik olarak şablon oluşturmak ve derlemek, özellikle kullanıcı verisi içeren şablonlar, Angular'ın yerleşik korumalarını atlar. Bu bir güvenlik anti-kalıbıdır. Formları güvenli bir şekilde dinamik olarak oluşturma hakkında bilgi için Dinamik Formlar kılavuzuna bakın.

Sunucu tarafı XSS koruması

Sunucuda oluşturulan HTML, enjeksiyon saldırılarına karşı savunmasızdır. Bir Angular uygulamasına şablon kodu enjekte etmek, uygulamaya çalıştırılabilir kod enjekte etmekle aynıdır: Saldırgana uygulama üzerinde tam kontrol verir. Bunu önlemek için sunucuda XSS güvenlik açıklarını önlemek amacıyla değerleri otomatik olarak kaçıran bir şablon dili kullanın. Sunucu tarafında bir şablon dili kullanarak Angular şablonları oluşturmayın. Bu, şablon enjeksiyonu güvenlik açıkları oluşturma riski yüksektir.

HTTP düzeyinde güvenlik açıkları

Angular, iki yaygın HTTP güvenlik açığını önlemeye yardımcı olmak için yerleşik desteğe sahiptir: siteler arası istek sahteciliği (CSRF veya XSRF) ve siteler arası komut dosyası dahil etme (XSSI). Her ikisi de öncelikle sunucu tarafında azaltılmalıdır, ancak Angular istemci tarafındaki entegrasyonu kolaylaştırmak için yardımcılar sağlar.

Siteler arası istek sahteciliği

Siteler arası istek sahteciliğinde (CSRF veya XSRF), bir saldırgan kullanıcıyı kötü amaçlı koda sahip farklı bir web sayfasını (örneğin evil.com) ziyaret etmeye kandırır. Bu web sayfası gizlice uygulamanın web sunucusuna (örneğin example-bank.com) kötü amaçlı bir istek gönderir.

Kullanıcının example-bank.com uygulamasına giriş yapmış olduğunu varsayın. Kullanıcı bir e-posta açar ve yeni bir sekmede açılan evil.com'a bir bağlantıya tıklar.

evil.com sayfası hemen example-bank.com'a kötü amaçlı bir istek gönderir. Belki de kullanıcının hesabından saldırganın hesabına para transferi isteğidir. Tarayıcı, kimlik doğrulama çerezi dahil example-bank.com çerezlerini bu istekle birlikte otomatik olarak gönderir.

example-bank.com sunucusu XSRF korumasına sahip değilse, uygulamadan gelen meşru bir istek ile evil.com'dan gelen sahte istek arasındaki farkı anlayamaz.

Bunu önlemek için uygulama, bir kullanıcı isteğinin farklı bir siteden değil, gerçek uygulamadan kaynaklandığından emin olmalıdır. Bu saldırıyı engellemek için sunucu ve istemci işbirliği yapmalıdır.

Yaygın bir anti-XSRF tekniğinde, uygulama sunucusu bir çerezde rastgele oluşturulmuş bir kimlik doğrulama token'ı gönderir. İstemci kodu çerezi okur ve sonraki tüm isteklerde token'lı özel bir istek başlığı ekler. Sunucu, alınan çerez değerini istek başlığı değeriyle karşılaştırır ve değerler eksikse veya eşleşmiyorsa isteği reddeder.

Bu teknik etkilidir çünkü tüm tarayıcılar aynı kaynak politikasını uygular. Yalnızca çerezlerin ayarlandığı web sitesindeki kod, o siteden çerezleri okuyabilir ve o siteye yapılan isteklerde özel başlıklar ayarlayabilir. Bu, yalnızca uygulamanızın bu çerez token'ını okuyabileceği ve özel başlığı ayarlayabileceği anlamına gelir. evil.com'daki kötü amaçlı kod yapamaz.

HttpClient XSRF/CSRF güvenliği

HttpClient, XSRF saldırılarını önlemek için kullanılan yaygın bir mekanizmayı destekler. HTTP istekleri gerçekleştirirken, bir interceptor varsayılan olarak XSRF-TOKEN adlı bir çerezden bir token okur ve onu X-XSRF-TOKEN HTTP başlığı olarak ayarlar. Yalnızca alanınızda çalışan kod çerezi okuyabildiğinden, arka uç HTTP isteğinin bir saldırgandan değil istemci uygulamanızdan geldiğinden emin olabilir.

Varsayılan olarak, bir interceptor bu başlığı tüm değiştirici isteklerde (örneğin POST) göreceli ve aynı kaynaklı URL'lere gönderir, ancak GET veya HEAD isteklerinde göndermez.

Bundan yararlanmak için sunucunuzun sayfa yüklemesinde veya ilk GET isteğinde XSRF-TOKEN adlı JavaScript tarafından okunabilir bir oturum çerezinde bir token ayarlaması gerekir. Sonraki isteklerde sunucu, çerezin X-XSRF-TOKEN HTTP başlığıyla eşleştiğini doğrulayabilir ve bu nedenle yalnızca alanınızda çalışan kodun isteği gönderebileceğinden emin olabilir. Token her kullanıcı için benzersiz olmalı ve sunucu tarafından doğrulanabilir olmalıdır; bu, istemcinin kendi token'larını oluşturmasını engeller. Token'ı, ek güvenlik için bir tuz ile sitenizin kimlik doğrulama çerezinin bir özetine ayarlayın.

Birden fazla Angular uygulamasının aynı alan veya alt alanı paylaştığı ortamlarda çakışmaları önlemek için her uygulamaya benzersiz bir çerez adı verin.

Özel çerez/başlık adlarını yapılandırma

Arka uç hizmetiniz XSRF token çerezi veya başlığı için farklı adlar kullanıyorsa, varsayılanları geçersiz kılmak için withXsrfConfiguration kullanın.

provideHttpClient çağrısına aşağıdaki gibi ekleyin:

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(
      withXsrfConfiguration({
        cookieName: 'CUSTOM_XSRF_TOKEN',
        headerName: 'X-Custom-Xsrf-Header',
      }),
    ),
  ],
};

XSRF korumasını devre dışı bırakma

Yerleşik XSRF koruma mekanizması uygulamanız için çalışmıyorsa, withNoXsrfProtection özelliğini kullanarak devre dışı bırakabilirsiniz:

export const appConfig: ApplicationConfig = {
  providers: [provideHttpClient(withNoXsrfProtection())],
};

Open Web Application Security Project (OWASP) adresindeki CSRF hakkında bilgi için Cross-Site Request Forgery (CSRF) ve Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet sayfalarına bakın. Stanford Üniversitesi makalesi Robust Defenses for Cross-Site Request Forgery zengin bir ayrıntı kaynağıdır.

Ayrıca Dave Smith'in AngularConnect 2016'daki XSRF konuşmasına da bakın.

Siteler arası komut dosyası dahil etme (XSSI)

Siteler arası komut dosyası dahil etme, JSON güvenlik açığı olarak da bilinir ve bir saldırganın web sitesinin bir JSON API'sinden veri okumasına izin verebilir. Saldırı, yerleşik JavaScript nesne oluşturucularını geçersiz kılarak ve ardından bir <script> etiketi kullanarak bir API URL'si dahil ederek eski tarayıcılarda çalışır.

Bu saldırı yalnızca döndürülen JSON JavaScript olarak çalıştırılabilir olduğunda başarılıdır. Sunucular, tüm JSON yanıtlarının önüne gelenek olarak bilinen ")]}',\n" dizesini ekleyerek yanıtları çalıştırılamaz hale getirerek saldırıyı önleyebilir.

Angular'ın HttpClient kütüphanesi bu geleneği tanır ve daha fazla ayrıştırmadan önce tüm yanıtlardan ")]}',\n" dizesini otomatik olarak çıkarır.

Daha fazla bilgi için bu Google web güvenliği blog yazısının XSSI bölümüne bakın.

Sunucu Tarafı İstek Sahteciliğini (SSRF) Önleme

Angular, başlık tabanlı Sunucu Tarafı İstek Sahteciliğini (SSRF) önlemek için istek işleme hattında Host, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Prefix ve X-Forwarded-Port başlıkları için katı doğrulama içerir.

Doğrulama kuralları şunlardır:

• Host ve X-Forwarded-Host başlıkları katı bir izin listesine göre doğrulanır ve yol ayırıcıları içeremez.
• X-Forwarded-Port başlığı sayısal olmalıdır.
• X-Forwarded-Proto başlığı http veya https olmalıdır.
• X-Forwarded-Prefix başlığı / ile başlamalı ve tek eğik çizgilerle ayrılmış yalnızca alfanümerik karakterler, tireler ve alt çizgiler içermelidir.
• Varsayılan olarak, tüm X-Forwarded-* başlıkları güvenilmez kabul edilir ve istekten kaldırılır. Bunları korumak için, trustProxyHeaders yapılandırılarak açıkça izin verilmeleri gerekir.

Geçersiz başlıklar bir hata günlüğü tetikler ve izin verilmeyen proxy başlıkları istekten kaldırılır. Tanınmayan ana bilgisayar adlarına sahip istekler 400 Bad Request ile sonuçlanır.

İzin verilen ana bilgisayarları yapılandırma

Belirli ana bilgisayar adlarına izin vermek için bunları izin listesine eklemeniz gerekir. Bu, uygulamanızın dağıtıldığında doğru ve güvenli bir şekilde çalışmasını sağlamak için kritik öneme sahiptir. Kalıplar, esnek ana bilgisayar adı eşleştirmesi için joker karakterleri destekler.

angular.json dosyanızda allowedHosts seçeneğini yapılandırabilirsiniz:

{
  // ...
  "projects": {
    "your-project-name": {
      // ...
      "architect": {
        "build": {
          "builder": "@angular/build:application",
          "options": {
            "security": {
              "allowedHosts": [
                "example.com",
                "*.example.com" // example.com'un tüm alt alan adlarına izin verir
              ]
            }
            // ... diğer seçenekler
          }
        }
      }
    }
  }
}

Uygulama motorunu başlatırken de allowedHosts yapılandırabilirsiniz:

const appEngine = new AngularAppEngine({
  allowedHosts: ['example.com', '*.trusted-example.com'],
});

const nodeAppEngine = new AngularNodeAppEngine({
  allowedHosts: ['example.com', '*.trusted-example.com'],
});

Node.js varyantı AngularNodeAppEngine için, ana bilgisayarları yetkilendirmek amacıyla NG_ALLOWED_HOSTS (virgülle ayrılmış liste) ortam değişkenini de sağlayabilirsiniz.

export NG_ALLOWED_HOSTS="example.com,*.trusted-example.com"

Güvenilen proxy başlıklarını yapılandırma

Varsayılan olarak, Angular tüm X-Forwarded-* başlıklarını yok sayar. Uygulamanız bu başlıkları ayarlayan güvenilen bir ters proxy'nin (yük dengeleyici gibi) arkasındaysa, Angular'ı bunlara güvenecek şekilde yapılandırabilirsiniz.

Uygulama motorunu başlatırken trustProxyHeaders yapılandırabilirsiniz:

const appEngine = new AngularAppEngine({
  trustProxyHeaders: ['x-forwarded-host', 'x-forwarded-proto'], // Belirli başlıklara güven
});

const nodeAppEngine = new AngularNodeAppEngine({
  trustProxyHeaders: true, // Tüm X-Forwarded-* başlıklarına güven
});

Node.js varyantı AngularNodeAppEngine için, bu başlıkların kullanımına izin vermek amacıyla NG_TRUST_PROXY_HEADERS ortam değişkenini de (değer olarak virgülle ayrılmış başlık listesiyle) sağlayabilirsiniz.

export NG_TRUST_PROXY_HEADERS="X-FORWARDED-HOST,X-FORWARDED-PREFIX"

Angular uygulamalarını denetleme

Angular uygulamaları, normal web uygulamalarıyla aynı güvenlik ilkelerine uymalı ve bu şekilde denetlenmelidir. Güvenlik incelemesinde denetlenmesi gereken bypassSecurityTrust yöntemleri gibi Angular'a özgü API'ler, belgelerde güvenlik açısından hassas olarak işaretlenmiştir.