Современные веб-приложения становятся все более критичными с точки зрения пользовательских данных и конфиденциальных бизнес-процессов. Однако эта возрастающая ценность также делает их целями для злоумышленников. Базовые меры безопасности, такие как использование HTTPS, безусловно, являются отправной точкой; однако их одних недостаточно. «Заголовки безопасности» HTTP, протокола связи между веб-браузерами и серверами, позволяют создать дополнительный уровень защиты, влияя на поведение браузера с вашим приложением.

В этой статье мы рассмотрим наиболее важные заголовки безопасности HTTP, которые сделают ваши веб-приложения более устойчивыми к распространенным атакам, как их настроить и почему вы должны их использовать, с практическими примерами кода.

1. HSTS (HTTP Strict Transport Security): Всегда HTTPS

HSTS — это политика безопасности, которая предписывает веб-браузерам взаимодействовать с определенным доменным именем только по HTTPS. Это предотвращает случайный доступ пользователя по HTTP или его переключение на HTTP при атаке типа «человек посередине» (MITM).

Как это работает? Как только сервер отправляет этот заголовок, браузер автоматически перенаправляет все будущие запросы для этого домена на HTTPS на указанный период времени (max-age), даже если пользователь вводит HTTP.

Пример реализации (Nginx):

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri; # Перенаправление HTTP на HTTPS
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    # ... другие конфигурации ...
}

max-age: Как долго браузер должен помнить эту политику (в секундах). Обычно используется 1 год (31536000 секунд).

includeSubDomains: Гарантирует, что эта политика также применяется ко всем поддоменам.

preload: Добавив свой домен в список предварительной загрузки HSTS, браузеры установят безопасное соединение с вашим сайтом даже при первом посещении. (Для добавления в список предварительной загрузки необходимо зарегистрировать свой сайт на hstspreload.org).

2. Content Security Policy (CSP): Предотвращение XSS и внедрения данных

CSP — это мощный заголовок безопасности, который позволяет указать, какие ресурсы (скрипты, стили, изображения и т. д.) может загружать веб-страница. Таким образом, даже если на вашем сайте есть уязвимость XSS (межсайтовый скриптинг), вы можете предотвратить загрузку или выполнение вредоносного кода.

Пример реализации (Nginx):

server {
    # ...
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; form-action 'self'; frame-ancestors 'none'; object-src 'none';";
    # ...
}

Пример реализации (Express.js - с пакетом Helmet):

const express = require('express');
const helmet = require('helmet');
const app = express();

app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://trusted.cdn.com"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:"],
    fontSrc: ["'self'"],
    formAction: ["'self'"],
    frameAncestors: ["'none'"],
    objectSrc: ["'none'"],
  },
}));

// ... другие маршруты и промежуточное ПО ...
app.listen(3000, () => console.log('Server running on port 3000'));

• default-src 'self': По умолчанию разрешает загрузку всех ресурсов только с вашего домена.
• script-src: Указывает источники скриптов. Избегайте использования 'unsafe-inline' и 'unsafe-eval'.
• style-src 'unsafe-inline': Разрешает встроенные стили. В крупных проектах этого также следует избегать, но иногда используется для совместимости.
• frame-ancestors 'none': Запрещает отображение вашей страницы в любом iframe (помогает предотвратить кликджекинг).

Важно тщательно разрабатывать CSP и сначала тестировать его с заголовком Content-Security-Policy-Report-Only.

3. X-Content-Type-Options: Предотвращение атак MIME-Sniffing

Этот заголовок запрещает браузеру «нюхать» содержимое, игнорируя заголовок Content-Type ответа. Это специально предотвращает ошибочное выполнение браузером файлов, загруженных пользователем (например, HTML-файла, загруженного как изображение).

Его значение может быть только nosniff.

Пример реализации (Nginx):

server {
    # ...
    add_header X-Content-Type-Options nosniff always;
    # ...
}

Пример реализации (Express.js - с пакетом Helmet):

app.use(helmet.noSniff());

4. X-Frame-Options: Защита от кликджекинга

Этот заголовок контролирует, может ли ваша веб-страница отображаться внутри <frame>, <iframe>, <embed> или <object>. Это предотвращает внедрение вашей страницы злонамеренным сайтом в свой собственный сайт и имитацию взаимодействия пользователя с элементами на вашей странице (кликджекинг).

• DENY: Страница не может отображаться ни в одном iframe.
• SAMEORIGIN: Страница может отображаться только в iframe из того же источника (того же домена).
• ALLOW-FROM uri: Страница может отображаться только в iframe из указанного uri (ограниченная поддержка современными браузерами, вместо этого рекомендуется использовать frame-ancestors из CSP).

Пример реализации (Nginx):

server {
    # ...
    add_header X-Frame-Options DENY always;
    # ...
}

Пример реализации (Express.js - с пакетом Helmet):

app.use(helmet.frameguard({ action: 'deny' })); // или 'sameorigin'

5. Referrer-Policy: Предотвращение утечки информации о реферере

Этот заголовок контролирует содержимое заголовка Referer (реферера), который браузер отправляет при выполнении запроса к другому сайту (например, при нажатии на ссылку или загрузке изображения). Это предотвращает утечку конфиденциальной информации третьим сторонам, если она передается в URL.

• no-referrer: Заголовок Referer полностью удаляется.
• no-referrer-when-downgrade: Referer не отправляется при переходе с HTTPS на HTTP.
• origin: Отправляется только домен-источник.
• same-origin: Referer отправляется только для запросов, сделанных из того же источника.
• strict-origin-when-cross-origin: Referer не отправляется при переходе с HTTPS на HTTP, полный URL отправляется для запросов из того же источника, и только источник для кросс-доменных запросов. (Рекомендуется в большинстве случаев.)

Пример реализации (Nginx):

server {
    # ...
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    # ...
}

Пример реализации (Express.js - с пакетом Helmet):

app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }));

6. Permissions-Policy (ранее Feature-Policy): Управление функциями браузера

Этот заголовок позволяет вам контролировать, может ли веб-страница или встроенный контент (iframe) использовать определенные функции браузера и API. Он повышает конфиденциальность пользователя, предотвращая вредоносное использование конфиденциальных функций, таких как камера, микрофон и местоположение.

Пример реализации (Nginx):

server {
    # ...
    add_header Permissions-Policy "microphone=(), camera=()"; # Полностью отключает микрофон и камеру.
    # add_header Permissions-Policy "geolocation=(self 'https://trusted.example.com')"; # Разрешает запросы геолокации только с собственного источника и trusted.example.com.
    # ...
}

Пример реализации (Express.js - с пакетом Helmet):

app.use(helmet.permissionsPolicy({
  features: {
    camera: ['none'],
    microphone: ['none'],
    geolocation: ["'self'", 'https://trusted.example.com'], // Пример
  },
}));

self: Разрешает доступ с собственного источника.

*: Разрешает доступ со всех источников.

none или (): Не разрешает доступ ни с какого источника.

Вы также можете указать конкретные URL.

Заключение

Заголовки безопасности HTTP составляют мощную линию защиты для ваших современных веб-приложений. Правильная настройка этих заголовков значительно укрепляет ваше приложение от XSS, кликджекинга, MIME-sniffing и многих других векторов атак. Помните, что безопасность — это непрерывный процесс, и помимо внедрения этих заголовков, вы также должны обеспечивать безопасность своих методов кодирования. Регулярный пересмотр состояния безопасности вашего приложения и следование лучшим практикам является ключом к защите ваших цифровых активов.