HTTP Strict Transport Security (HSTS) — veb saytların brauzerlərə "mənə yalnız HTTPS üzərindən müraciət et" deməsidir.

HSTS ilə sən brauzerə deyirsən ki, "Mən sadəcə HTTPS ilə sorğu gözləyirəm. Brauzer bunu yadında saxlayır və bundan sonra istifadəçi http:// yazsa belə, brauzer özü avtomatik https:// yə çevirir — serverə HTTP sorğusu heç getmir.

Niyə sadəcə redirect kifayət etmir?

301 Redirect-dən http:// → https:// yönləndirmə kifayətdir. Texniki olaraq doğrudur. Amma təhlükəsizlik baxımından bu, boşluq yaradır.

Real ssenaridə baxaq:

İstifadəçi brauzerə yazır: http://aghayev.dev
1. Brauzer → HTTP sorğusu göndərir (şifrələnməmiş)
2. Server → 301 Redirect: https://aghayev.dev
3. Brauzer → HTTPS-ə keçir

Amma 1-ci və 2-ci addım arasında nə baş verir?

Bu aradakı millisaniyələr kifayətdir ki, şəbəkədəki hacker:

  • Redirect-i ələ keçirsin və istifadəçini saxta HTTP versiyaya yönləndirsin (protocol downgrade)
  • Cookie-ləri oxusun — HTTP sorğusu ilə gedən cookie-lər şifrələnmir
  • Browsing tarixçəsini görsün — hansı URL-ə getdiyiniz şəbəkədəki hərkəsə görünür

HSTS isə bu problemi kökündən həll edir:

İstifadəçi brauzerə yazır: http://aghayev.dev
1. Brauzer HSTS siyahısını yoxlayır
2. "Bu domain HSTS-lidir" → HTTP-ni HTTPS-ə çevirir (307 Internal Redirect)
3. Brauzer → HTTPS sorğusu göndərir (şifrələnmiş)
Serverə HTTP sorğusu HEÇ VAXT getmir.

Fərqi gördünüz? Redirect server tərəfində baş verir (şəbəkə hücumuna açıqdır), HSTS isə brauzer tərəfində baş verir (şəbəkəyə HTTPS ilə çıxır).

HSTS necə işləyir?

Mexanizm çox sadədir. Server HTTPS cavablarına bir header əlavə edir:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Bu header brauzerə deyir:

  • max-age=31536000 → "Növbəti 1 il ərzində bu domainə yalnız HTTPS ilə gəl"
  • includeSubDomains → "Bu qayda bütün subdomain-lərə də aiddir"

Brauzer bu header-i aldıqdan sonra, həmin domain üçün daxili bir qeyd yaradır. Bundan sonra istifadəçi http:// yazsa belə, brauzer heç serverə müraciət etmədən özü HTTPS-ə çevirir.

HSTS hücum ssenarilərinin qarşısını necə alır?

Tutaq ki, hacker kafedəki açıq Wi-Fi şəbəkəsindədir və istifadəçi http://aghayev.dev-a daxil olmaq istəyir.

HSTS olmadan

İstifadəçi brauzerə yazır: aghayev.dev

[İstifadəçi] ──HTTP──→ [Hacker (Man-in-the-Middle)] ──HTTP──→ [Server]

Hackerin gördükləri (HTTP ilə):

GET /dashboard HTTP/1.1
Host: aghayev.dev
Cookie: session_id=abc123xyz   ← Session oğurlanır!
POST /login HTTP/1.1
Host: aghayev.dev
user=ali&password=SuperSecret123  ← Parol açıq görünür!

HSTS ilə

İstifadəçi brauzerə yazır: http://aghayev.dev
[Brauzer] → HSTS yoxlayır → "aghayev.dev HSTS-lidir"
           → Avtomatik https://aghayev.dev edir (sorğu hələ şəbəkə çıxmayıb)           → Şifrələnmiş TLS bağlantısı qurulur
[İstifadəçi] ──HTTPS──→ [Hücumçu] ──???──→ [Server]

Hücumçunun gördükləri (HTTPS ilə):

[Encrypted TLS data]
1a 2b 3c 4d 5e 6f... ← Heç nə anlaşılmır.

SSL Strip (Protocol Downgrade) hücumu nədir?

HSTS-in niyə vacib olduğunu anlamaq üçün SSL Strip hücumuna baxaq:

HSTS olmadan — SSL Strip işləyir:
İstifadəçi → http://aghayev.dev
Hacker araya girir və:
  1. Server ilə HTTPS bağlantısı qurur 
  2. İstifadəçiyə HTTP ilə cavab verir (şifrəsiz)
  3. Səhifədəki https:// linklərini http:// ilə əvəz edir
Nəticə: İstifadəçi "secure" saytda olduğunu düşünür, 
  amma trafiki şifrəsiz gedir!
HSTS ilə — SSL Strip işləmir:
Brauzer artıq bilir ki, aghayev.dev HSTS-lidir
HTTP cavabını qəbul etməkdən imtina edir
Bağlantı tamamilə kəsilir — hücum uğursuz olur

Necə implementasiya etmək olar?

Edilməməli olan ilkin konfigürasiya— HSTS-i birbaşa max-age=31536000 ilə aktiv etməkdir. Bu, bir il ərzində geri dönüşü olmayan qərardır. Əgər hansısa subdomain HTTPS-i dəstəkləmirsə, istifadəçilər həmin subdomain-ə daxil ola bilməyəcək.

Düzgün yanaşma pilləli artırmadır:

Mərhələ 1 (5 dəqiqə — test üçün):
Strict-Transport-Security: max-age=300; includeSubDomains

Mərhələ 2 (1 həftə):
Strict-Transport-Security: max-age=604800; includeSubDomains

Mərhələ 3 (1 il — production):
Strict-Transport-Security: max-age=31536000; includeSubDomains

Hər mərhələdə domain və subdomainlərin düzgün işlədiyini yoxlayırsan. Metrikləri (traffic, revenue, error rate) izləyirsən. Problem yoxdursa, növbəti mərhələyə keçirsən. Problem varsa, max-age bitənə qədər gözləyib düzəldirsən.

Nginx konfiqurasiyası:

server {
    listen 443 ssl;
    server_name aghayev.dev;
    
    # HSTS header — yalnız HTTPS cavablarında göndər
    add_header Strict-Transport-Security 
        "max-age=31536000; includeSubDomains" always;
}
server {
    listen 80;
    server_name aghayev.dev;
    
    # HTTP-dən HTTPS-ə redirect (HSTS bu redirect-dən sonra işə düşür)
    return 301 https://$host$request_uri;
}

Express.js (Node.js) ilə:

const helmet = require('helmet')
app.use(helmet.hsts({
  maxAge: 31536000,        // 1 il (saniyə ilə)
  includeSubDomains: true, // Subdomain-lər də daxil
}))

Yaxud middleware ilə:

app.use((req, res, next) => {
  if (req.secure) {
    res.setHeader(
      'Strict-Transport-Security',
      'max-age=31536000; includeSubDomains'
    )
  }
  next()
})

Qeyd: HSTS header-i yalnız HTTPS cavablarında göndərilməlidir. HTTP cavabında göndərsən, brauzer bunu ignore edəcək — bu, protokolun tələbidir. Çünki HTTP cavabının özü etibarsızdır və hücumçu tərəfindən dəyişdirilə bilər.

Preload problemi və həlli

HSTS-in bir zəifliyi var, ilk ziyarət. Brauzer domain-in HSTS siyasətini yalnız ilk HTTPS cavabından öyrənir. Yəni istifadəçi saytı ilk dəfə ziyarət edəndə, HSTS hələ aktiv deyil və o MitM (Man-in-the-Middle) hücuma açıqdır.

HSTS Preload bu problemi həll edir. Chrome, Firefox, Safari və Edge brauzerləri daxili siyahı saxlayır, bu siyahıda olan domainlərə brauzer heç vaxt HTTP ilə getmir, hətta ilk ziyarətdə belə.

Preload siyahısına daxil olmaq üçün tələblər:

1. SSL sertifikat
2. Port 80-dən HTTPS-ə redirect 
3. Bütün subdomain-lər HTTPS üzərindən xidmət etməlidir
4. HSTS header-ində:
   - max-age ən azı 31536000 (1 il)
   - includeSubDomains direktivi
   - preload direktivi

Header belə görünməlidir:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Sonra isə hstspreload.org saytından domain-i submit edirsən.

⚠️ Preload haqqında ciddi xəbərdarlıq

Preload geri dönüşü çətin olan qərardır. Domain siyahıya daxil olduqdan sonra, onu çıxarmaq aylar çəkə bilər — çünki siyahı brauzer yeniləmələri ilə yayılır.

Necə problem yarada bilər?: Developer HTTPS-i sınaqdan keçirir, preload-u aktiv edir. Sonra anlayır ki, daxili example.aghayev.dev subdomain-i HTTPS dəstəkləmir. Amma artıq gec olur — brauzer həmin subdomain-ə HTTP ilə getməkdən imtina edir. Və siyahıdan çıxmaq üçün aylarca gözləmək lazımdır.

Buna görə preload-u yalnız bütün infrastrukturunuzun HTTPS-i tam dəstəklədiyinə əmin olduqda aktiv edin. Əvvəlcə HSTS-i preload-suz istifadə edin, pilləli artırın, hər şeyi test edin — sonra preload əlavə edin.

Developer üçün checklist

Production-a deploy etməzdən əvvəl bu siyahıdan keçin:

□ Bütün subdomain-lər HTTPS ilə işləyir
□ HTTP → HTTPS redirect mövcuddur (301)
□ HSTS header yalnız HTTPS cavablarında göndərilir (nginx conf)
□ includeSubDomains aktiv edilib
□ CDN/Load Balancer varsa, header-in override edilmədiyini yoxlayın
□ Preload — yalnız tam hazır olduqda

Son Söz

Təhlükəsizlik məsələləri əksər developerlərin "sonra edərəm" siyahısında olur. Amma HSTS kimi sadə bir header istifadəçilərinizi ciddi hücumlardan qoruya bilər.

Süni intellektin bu qədər sürətli şəkildə kod yazdığı dövrdə, təhlükəsizliyin niyə lazım olduğunu anlamaq daha da vacibdir.

Əgər bu məqalə sizə kömək etdisə, 👏 vurmağı unutmayın. Suallarınız varsa, şərhlərdə görüşək!

Mənbələr: