Как выполняется JS?

HTTPS безопасность — как она работает

HTTPS (HTTP Secure) использует **TLS/SSL шифрование** для защиты данных. Это критично для frontend разработчика.

1. Шифрование данных (Encryption)

HTTP отправляет данные в открытом виде:

Client -> [Plain text: password=secret] -> Server
          ↑ Может быть перехвачено

HTTPS шифрует данные:

Client -> [Encrypted: 8aH$%@#$%x2@] -> Server
          ↑ Невозможно прочитать без ключа

Типи шифрования:

• Symmetric — один ключ для шифрования и расшифровки
• Asymmetric — разные ключи (public и private)
• HTTPS использует оба: асимметричное для обмена ключами, симметричное для данных

2. Аутентификация сервера (Server Authentication)

HTTPS проверяет что сервер — это действительно он:

Ситуация: Хакер перехватывает трафик

HTTP:
Client -> [plain] -> Attacker (выдаёт себя за Server)
                     Attacker получает пароль!

HTTPS:
Client -> проверяет сертификат сервера
       -> ОК, это действительно example.com
       -> Продолжаем с шифрованием
       ✓ Защищено

Как это работает:

1. Сервер отправляет SSL/TLS сертификат
2. Client проверяет:
   • Подпись от доверенного CA (Certificate Authority)
   • Домен совпадает
   • Сертификат не истёк
3. Если всё OK — соединение безопасно

Frontend видит это:

// В браузере
// 1. Зелёный замочек = HTTPS с валидным сертификатом
// 2. Красный замочек = HTTPS но сертификат неверный
// 3. Нет замочка = HTTP (небезопасно)

// JavaScript
const protocol = window.location.protocol;
if (protocol === 'https:') {
  // Безопасное соединение
} else {
  console.warn('Unsafe connection!');
}

3. Целостность данных (Integrity)

HTTPS гарантирует что данные не были изменены:

HTTP:
Client отправляет: {amount: 100}
На пути хакер меняет на: {amount: 10000}
Server получает: {amount: 10000} ← проблема!

HTTPS:
Client отправляет: {amount: 100, hash: abc123}
Хакер меняет на: {amount: 10000, hash: abc123}
Server проверяет: хеш не совпадает!
Данные отклонены ← защищено

Используется HMAC (Hash-based Message Authentication Code).

4. Perfect Forward Secrecy (PFS)

Если приватный ключ сервера украдут, старые сеансы остаются в безопасности:

HTTPS с PFS:
1. Каждый сеанс получает уникальный временный ключ
2. Даже если сервер скомпрометирован, старые данные защищены
3. Только текущий сеанс в опасности

5. HSTS — принуждение HTTPS

Сервер говорит браузеру: "Всегда используй HTTPS"

HTTP Response Header:
Strict-Transport-Security: max-age=31536000; includeSubDomains

Влияние на frontend:
- Браузер автоматически переводит http -> https
- Защитает от downgrade атак
- Кэшируется в браузере

Использование:

// После получения HSTS header,
// все последующие запросы будут https://

// Раньше: http://example.com -> redirect -> https://example.com
// Теперь: (локальный редирект в браузере)

6. Certificate Pinning

Frontend проверяет что сертификат совпадает с ожидаемым:

// Для production приложений
const expectedCertFingerprint = 'abc123def456';

fetch('https://api.example.com/data')
  .then(response => {
    // Проверяем сертификат (в native app, не в браузере)
    // Браузер не предоставляет API для этого,
    // но нативное приложение может
  });

Как HTTPS защищает frontend

Сценарий 1: Man-in-the-Middle (MITM) атака

Без HTTPS:
User -> [Password] -> Attacker (Wi-Fi) -> Server
Аттакер видит пароль!

С HTTPS:
User -> [Encrypted] -> Attacker (Wi-Fi) -> Server
Аттакер видит только шифрованные данные
Невозможно расшифровать без ключа

Сценарий 2: Phishing через перехват

Без HTTPS:
Attacker создаёт поддельный сайт
Пользователь видит: http://bankk.com (опечатка?)
Или: http://legitimate.attacker.com
Нет признаков что это не настоящий сайт

С HTTPS:
Если https://bank.com в адресной строке
А браузер показывает зелёный замочек
То это действительно bank.com
Одна опечатка = «untrusted certificate»

Что видит frontend разработчик

// 1. HTTPS маячки в браузере
if (!window.location.href.startsWith('https://')) {
  console.warn('Not using HTTPS!');
}

// 2. Mixed Content warning
// Если страница HTTPS но загружает ресурсы с HTTP
<img src="http://example.com/image.jpg" />
// Браузер выдаст ошибку (блокирует)

// 3. Cookies с флагом Secure
// Cookie автоматически удаляется если сайт на HTTP
document.cookie = 'token=abc; Secure; HttpOnly';

// 4. Insecure Content Policy
Content-Security-Policy: upgrade-insecure-requests
// Браузер автоматически преобразует http -> https

Чек-лист HTTPS для frontend

• Все ресурсы должны быть HTTPS (изображения, CSS, JS, fonts)
• Нет Mixed Content (HTTP на HTTPS странице)
• Cookies с флагом Secure и HttpOnly
• Content-Security-Policy установлена
• HSTS header присутствует
• Сертификат валидный (не истёк)
• Нет самоподписанных сертификатов в production

Performance

HTTPS немного медленнее, но современные браузеры это минимизировали:

HTTP:  50ms  ← быстро
HTTPS: 52ms  ← практически то же самое

HTTP/2 over TLS (HTTPS/2): 48ms ← даже быстрее!

Плюс производительности HTTPS:

• HTTP/2 требует HTTPS
• Better caching с HSTS preload
• Faster на современных браузерах

Вывод

HTTPS защищает от:

• Перехвата данных (sniffing)
• Изменения данных (tampering)
• Phishing и мошенничества
• Man-in-the-Middle атак

Frontend должен:

• Использовать HTTPS везде в production
• Не загружать незащищённые ресурсы
• Передавать sensitive данные только через HTTPS
• Использовать secure флаги для cookies

В 2025 году: HTTPS это стандарт, а не опция.