HTTP와 같은 일반 텍스트 프로토콜은 공격자가 전송된 콘텐츠를 읽을 수 있는 도청 공격에 취약할 수 있습니다. 다행히 전송 계층 보안 (TLS)을 사용하면 트래픽을 암호화할 수 있으며, 공격자가 이 데이터를 캡처하더라도 이를 사용하는 것이 훨씬 더 어려워집니다.
하지만 공격자가 암호화된 연결을 일반 텍스트 HTTP를 사용하도록 강제하여 TLS를 우회할 수 있습니다. 이 문제를 해결하기 위해 HTTP Strict Transport Security(HSTS) 응답 헤더가 도입되었습니다. 이 헤더는 사용자의 브라우저가 TLS만 사용하여 웹사이트를 방문하도록 강제하고 일정 시간 동안 일반 텍스트 HTTP로 대체되지 않도록 합니다.
Lighthouse 감사 실패 방식
감사에서는 HSTS 헤더와 관련하여 다음 문제를 신고합니다.
- HSTS 헤더가 전혀 발견되지 않은 경우
- 권장 지시어 중 하나가 누락된 경우 (
max-age,includedSubDomains,preload) max-age지시문의 기간이 1년 (31,536,000초) 미만인 경우- 알 수 없는 지시문과 같이 헤더를 파싱할 때 구문 오류가 있는 경우
강력한 HSTS 정책 구성
최적의 HSTS 헤더 구성은 다음과 같습니다.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
max-age디렉티브는 사용자의 브라우저가 TLS만 사용하여 웹사이트를 방문해야 하는 시간을 초 단위로 지정합니다. 그 후에는 웹사이트에서 HSTS 헤더를 제공하지 않거나 HTTP에서 HTTPS로의 임시 리디렉션이 적용된 경우 일반 HTTP를 사용하여 사이트에 다시 액세스할 수 있습니다.includeSubDomains디렉티브를 설정하면 처음에 헤더를 전송하는 페이지 URL의 모든 하위 도메인에 헤더가 적용됩니다. 예를 들어 google.com에서includeSubDomains지시어가 포함된 HSTS 헤더를 전송하면 mail.google.com에서도 HSTS 헤더가 적용됩니다.preload디렉티브를 설정하고 도메인을 HSTS 미리 로드 서비스에 제출하면 도메인이 Google Chrome뿐만 아니라 미리 로드된 HSTS 목록을 사용하는 브라우저 바이너리로 컴파일됩니다.
HSTS 헤더를 출시할 때는 몇 가지 위험이 있습니다. 암호화되지 않은 HTTP 연결이 필요한 모든 기능은 max-age 디렉티브에 설정된 시간 동안 효과적으로 중단됩니다. preload 지시어가 적용되는 경우 더 오래 걸릴 수 있습니다.
출시와 관련된 위험을 줄이려면 단계적 접근 방식을 사용하는 것이 좋습니다.
작은
max-age로 시작하고includeSubDomains만 추가합니다 (preload는 안 됨).max-age=3600; includeSubDomains문제가 신고되지 않은 쿨다운 기간 (예: 1주일)이 지나면
max-age를 올립니다.예를 들면 다음과 같습니다.max-age=604800; includeSubDomains이 초기 단계가 장기간 (예: 3개월) 성공적으로 진행되면 웹사이트와 하위 도메인을 HSTS 미리 로드 목록에 추가하고
preload디렉티브를 추가해야 합니다.max-age=63072000; includeSubDomains; preload