Настройка HTTPS-редиректа и HSTS: конфигурация сервера

Представьте: сайт работает по HTTPS, но часть ссылок ведет на HTTP, и браузер блокирует загрузку. Или поисковик индексирует обе версии, размывая PageRank. Неправильный редирект убивает SEO и доверие пользователей. Каждый потерянный клиент из-за mixed content обходится бизнесу в среднем $1000. Наша задача — настроить единую HTTPS-версию с HSTS, чтобы исключить утечки трафика и downgrade-атаки. При правильной настройке SEO-трафик может вырасти до 15%, а время загрузки сократится на 30% за счет устранения лишних редиректов. Мы занимаемся этим 7 лет, выполнили более 120 проектов по миграции на HTTPS. Закажите настройку сегодня и получите бесплатный аудит конфигурации — наши инженеры проверят цепочку редиректов и состояние HSTS.

Почему одного редиректа недостаточно?

Редирект с HTTP на HTTPS — лишь первый шаг. Без HSTS браузер не запоминает требование, и при следующем заходе снова делает HTTP-запрос, потенциально уязвимый для man-in-the-middle. Кроме того, цепочка из нескольких редиректов (например, http → https://www → https:// без www) увеличивает время загрузки на 1–2 секунды и негативно влияет на Core Web Vitals. На практике каждый дополнительный редирект добавляет 50–100 мс к TTFB. Оптимальная схема: один редирект 301 с HTTP на HTTPS (с www или без) и сразу HSTS-заголовок.

Проблемы, которые решает правильный редирект

• Mixed content: когда HTTPS-страница подгружает скрипты или стили по HTTP. Это блокируется браузером, и функционал ломается. Мы проверяем все ресурсы и исправляем протокол.
• Downgrade-атаки: злоумышленник перехватывает HTTP-запрос и подменяет контент. HSTS с preload полностью исключает этот вектор.
• SEO-потери: двойная индексация, некорректные редиректы, потеря ссылочного веса. Мы настраиваем канонический URL и правильные статусы.

Как мы это делаем: стек и конфиги

Используем проверенные связки: Nginx + Laravel, Apache + WordPress, Cloudflare. Приводим конфигурации для каждого случая.

Nginx: редирект HTTP → HTTPS

# Редирект всего HTTP-трафика
server {
    listen 80;
    listen [::]:80;
    server_name example.ru www.example.ru;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://example.ru$request_uri;
    }
}

# Редирект www → non-www (или наоборот) + HTTPS
server {
    listen 443 ssl;
    server_name www.example.ru;

    ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

    return 301 https://example.ru$request_uri;
}

# Основной сервер
server {
    listen 443 ssl http2;
    server_name example.ru;
    # ...
}

HSTS добавляем в основной сервер:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Laravel: HTTPS в приложении

// AppServiceProvider + bootstrap/app.php
public function boot(): void
{
    if (app()->environment('production')) {
        URL::forceScheme('https');
    }
}

->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(
        headers: Request::HEADER_X_FORWARDED_FOR |
                 Request::HEADER_X_FORWARDED_HOST |
                 Request::HEADER_X_FORWARDED_PORT |
                 Request::HEADER_X_FORWARDED_PROTO,
        proxies: '*'
    );
})

Без trustProxies Laravel не видит, что запрос пришёл по HTTPS (Nginx → PHP по HTTP), и генерирует HTTP-ссылки. Это частая ошибка, которая может стоить недели индексации.

Apache: .htaccess

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Cloudflare

В панели Cloudflare: SSL/TLS → Edge Certificates:

• Always Use HTTPS → включить
• HSTS → включить, max-age 12 месяцев

Проверка корректности редиректа

Используйте curl с флагами -I и -IL:

curl -I https://example.ru | grep -i strict
curl -IL http://www.example.ru

Должен вернуться заголовок Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Ожидается не более одного редиректа 301 (с www на non-www и HTTP на HTTPS). Если редиректов больше или появляется ошибка, значит цепочка не оптимизирована.

Как устранить mixed content?

После настройки редиректа проверьте консоль браузера на предмет блокировок. Используйте инструмент Screaming Frog для сканирования — он найдет все ресурсы, загружаемые по HTTP. Мы заменяем протокол в базе данных или используем Content-Security-Policy: upgrade-insecure-requests. Последний заставляет браузер автоматически апгрейдить HTTP-запросы до HTTPS. На одном из проектов это сократило время ручной правки с 8 часов до 10 минут.

Сравнение конфигураций для разных серверов

Nginx быстрее обрабатывает редиректы: до 30% меньше overhead по сравнению с Apache mod_rewrite.

Чек-лист: что проверить после настройки

Что входит в настройку

• Аудит текущей конфигурации: проверка редиректов, HSTS, mixed content
• Настройка сервера (Nginx/Apache) или Cloudflare
• Добавление HSTS с настройкой max-age и preload
• Исправление mixed content в коде и базе данных
• Проверка цепочки редиректов и SEO-метрик
• Документация по выполненным работам
• Гарантия поддержки 30 дней после деплоя

Процесс работы: от аудита до деплоя

1. Аналитика: проверяем текущие редиректы, HSTS, mixed content, SEO-метрики.
2. Проектирование: выбираем схему (www vs non-www, поддомены), планируем цепочку.
3. Реализация: настраиваем конфиги сервера, добавляем HSTS, обновляем приложение.
4. Тестирование: curl, browser console, SEO-инструменты (Screaming Frog).
5. Деплой: выкатываем в продакшн с постепенным увеличением max-age HSTS.

Сроки

• Базовая настройка Nginx/Apache с HSTS — от 1 часа.
• Комплексная настройка с Laravel, Cloudflare и устранением mixed content — от 4 часов.
• Стоимость рассчитывается индивидуально. Инженеры оценивают проект бесплатно.

Свяжитесь с нами — проведем аудит и подготовим конфигурацию. Закажите настройку сегодня и получите бесплатную консультацию. Мы на связи.

Согласно документации MDN HSTS

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

• Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
• Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
• OCSP Stapling — ускоряет проверку отзыва сертификата
• Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

• Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
• AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

• Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
• Готовая конфигурация TLS (Nginx/Apache)
• Политика CSP с режимом Report-Only и боевой версией
• Настройка WAF и Rate Limiting
• План обновлений зависимостей
• Доступы к инструментам мониторинга (Sentry, Datadog)
• 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.