Kapital Letter Tech Blog

[태그:] HTTPS

  • PWA 배포와 진단, 그리고 한계

    HTTPS, PWA의 출발선

    PWA는 HTTPS 환경에서만 동작한다.

    Service Worker가 네트워크 요청을 가로채는 구조이기 때문에,

    보안되지 않은 연결(HTTP)에서는 이를 차단한다.

    단순한 보안이 아니라 신뢰 체인의 시작

    앞서 Service Worker가 네트워크 요청을 가로채는 구조라고 언급했다.

    즉 이를 통해 보안을 전제로 성립하지 않으면, 악성 스크립트가 중간에서 데이터를 변조하기에

    매우 좋다는 위험성을 내포한다는 것을 알 수 있다.

    따라서, HTTPS 환경은 PWA에서 매우 기본적 전제 조건으로 성립한다.

    (애초에 브라우저는 HTTPS 환경이 아니라면 PWA를 등록조차 하지 않는다)

    실무에서의 HTTPS 이슈

    1. 내부망(사내망) 개발 환경

    사설 인증서(Self-signed Certificate)를 사용하는 경우, Chrome은 기본적으로

    Service Worker 등록을 차단한다.

    → chrome://flags/#allow-insecure-localhost 옵션을 임시 허용하거나, mkcert / local CA 기반 개발 인증서 사용

    2. 멀티 도메인 환경

      Service Worker의 scope는 도메인 단위로 묶인다.

      리소스를 다른 서브도메인에서 캐싱하려면 CORS + HTTPS 동일 정책 필수.

      → 동일 origin 정책을 고려하여 serviceWorker.register(’/sw.js’, { scope: ‘/’ }) 구성 조정.

      3. SSL 갱신 자동화 이슈

        HTTPS 인증서가 만료되면 PWA는 즉시 installable 자격을 상실한다.

        (브라우저가 신뢰할 수 없는 컨텍스트로 판단한다.)

        따라서 CI/CD 파이프라인에서 certbot renew 또는 Cloudflare API 기반

        SSL 자동 갱신 스크립트 포함 필요.

        4. Mixed Content 차단

          HTTPS 페이지 내에서 HTTP 자원을 요청하면 Service Worker는 정상 작동하지 않는다.

          해당 요청은 네트워크 캐시에도 등록되지 않는다.



          PWA 품질 진단

          Chrome DevTools의 Lighthouse는 PWA 품질을 자동으로 분석해준다.

          평가 항목은 다음과 같다.

          PWA 품질 평가 항목

          • Installable: HTTPS, Manifest, Service Worker 등 설치 조건 충족 여부
          • Performance: LCP, FID, CLS 등 핵심 성능 지표
          • Best Practices: 보안 및 접근성 검증
          • Accessibility: 시각적, 키보드 접근성 테스트
          • SEO: 검색엔진 메타 구성 확인

          PWA 품질 진단 실행

          [DevTools] – [Lighthouse 탭] – [Progressive Web App] 선택,

          결과 리포트에서 Installable 과 Offline ready 항목이 모두 초록색이면 OK

          *고품질의 PWA

          오프라인 대응 + HTTPS + Manifest + 빠른 로딩 + 접근성 확보


          캐시 버전 관리

          PWA의 가장 큰 함정은 캐시 갱신이 느리다는 것,

          Service Worker는 안정성을 위해 자동으로 새 버전을 즉시 활성화하지 않는다.

          이로 인해 사용자가 이전 캐시를 여전히 보고 있을 가능성이 존재하고,

          새로운 코드가 배포되어도 즉시 반영되지 않게 된다.

          해결하려면

          • 캐시 버전 + 업데이트 알림
          • 클라이언트 측에서 새 버전 감지 시 알림 띄우기

          오프라인 테스트

          PWA 배포가 끝나면 오프라인 시나리오 테스트 진행이 필요하다.

          Chrome DevTools → [Application] → [Service Workers] → Offline 체크 → 새로고침

          이 과정에서 캐시된 콘텐츠가 보이면 정상 작동이다.

          • 추가로 점검해야 할 사항
            • 새로고침 시 캐시된 버전이 즉시 뜨는가?
            • fetch 실패 시 fallback 페이지(offline.html)로 전환되는가?
            • Service Worker가 업데이트될 때 새 버전 적용이 정상인가?

          PWA의 한계

          여전히 제한적인 PWA

          브라우저별로 Service Worker의 업데이트 시점이 불균일하고, 캐시 관리 복잡도 및 네트워크 동기화 지연 이슈로 현재까지는 아직 PWA에서 한계가 보인다. 또한, iOS에서 PWA에 대한 지원을 제약하기 때문에 PWA는 완성된 기술이 아닌 진화 과정의 일부 단계로 보인다.

          iOS에서의 PWA 제약

          iOS(Safari)의 PWA 지원은 여전히 제약적이고 Apple은 보안 및 배터리 이슈를 이유로 일부 기능을 막고 있다.

          기능지원 여부비고
          Push NotificationiOS 16.4+제한적 지원, 유저 승인 필요
          Background SyncX불가능
          Storage(Cache Size)약 50MB 한도자동 삭제 가능성 있음
          Install PromptX (자동 배너 없음)홈 화면에 추가 수동 유도
          Web Bluetooth / USBX미지원 API 다수

        1. HTTPS TLS, HSTS

          HTTP의 한계

          기본적으로 HTTP 프로토콜은 평문(plain text)으로 데이터를 주고 받고,

          이는 로그인 정보, 세션 쿠키, API 응답 등 모든 통신 내용이 노출될 수 있는 위험을 내포한다.

          이런 HTTP의 한계를 이용한 대표적인 공격으로는

          중간자 공격(MITM, Man-in-the-Middle)이 있으며, 공격자는 이 공격을 통해 사용자의 네트워크

          트래픽을 가로채고 내용을 열람하거나 수정할 수 있다. (e.g. 카페 와이파이에서 비밀번호 유출)

          이를 해결하기 위해, 평문의 데이터를 전송, 즉 주고 받을 때

          이 전송 구간을 암호화(Encryption) 하는 것을 도입하고자 했다.

          이 암호화를 수행하는 기술을 TLS(Transport Layer Security) 라 한다.

           

          TLS?

          웹 통신을 암호화하기 위한 표준 프로토콜,

          이전에는 SSL(Secure Sockets Layer)이라 불렸지만, 여러 보안 결함이 발견되었다.

          여러 보안 결함들을 해결하고 추가적인 보안 기능을 제공하도록 개선된 것이 TLS(버전 업그레이드).

          TLS는 통신 과정에서 다음 세 가지를 보장한다.

          • 기밀성(Confidentiality): 제3자가 데이터를 읽을 수 없음.
          • 무결성(Integrity): 데이터가 중간에서 변조되지 않음.
          • 인증(Authentication): 서버 또는 클라이언트가 신뢰할 수 있는 대상임을 검증.

           

          TLS 핸드셰이크 과정

          TLS는 실제 데이터 전송 전에 암호화된 연결을 수립(handshake)한다.

           

          Client Hello

          브라우저(클라이언트)가 서버에 TLS를 사용하고 싶은 의사와 가능한 암호화 알고리즘을 제안한다.

           

          Server Hello

          서버가 암호화 알고리즘을 선택, 공개키가 담긴 SSL 인증서를 전달한다.

           

          인증서 검증

          브라우저는 이 인증서가 신뢰할 수 있는 기관(CA, Certificate Authority)에서 발급된 것인지 검증,

          인증서에 포함된 도메인, 만료일, 서명 정보 등을 검사한다.

           

          비밀키 교환

          브라우저와 서버는 공개키 암호화를 통해 세션 키를 교환,

          이후 데이터는 이 세션 키로 대칭 암호화되어 통신한다.

           

           

          HTTPS는 TLS 위의 HTTP

          HTTPS = HTTP + TLS

          HTTP의 내용(요청 메서드, 헤더, 바디 등)은 그대로, ‘전송하는 과정’만 암호화한다.

          HTTPS의 효과

          • 통신 중 비밀번호, 쿠키, API 응답이 노출되지 않음.
          • 세션 하이재킹(Session Hijacking), 쿠키 탈취 등의 위험이 크게 줄어든다.
          • HTTP/2, HTTP/3 등 최신 프로토콜은 모두 HTTPS를 기반으로 동작.

           

          HSTS(HTTP Strict Transport Security)

          HTTPS를 적용했다고 완전히 안전한 것은 아니다.

          최초 접속이 HTTP로 이루어지는 상황을 생각해보자.

          e.g.

          사용자가 http://example.com 을 입력하여 접속 시도,

          브라우저에서는 먼저 HTTP로 요청 → 서버가 301 리다이렉트 → HTTP로 이동하게 된다.

          이때, 이 첫 요청 사이에 공격자가 개입하면 여전히 중간자 공격 가능성이 존재하게 된다.

          HSTS로 해결할 수 있다

          HSTS는 서버가 브라우저에 다음 헤더를 내려주는 방식이다.

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

          이후 브라우저는 해당 도메인에 대해,

          • 무조건 HTTPS로만 접속하도록 강제.
          • HTTP 요청 시도하지 않음(리다이렉트 이전에 차단)
          • preload 옵션을 등록 시 주요 브라우저의 HSTS Preload List에 도메인이 포함되어, 첫 방문 전에 HTTPS만 사용 가능.

          즉, 사용자가 HTTP로 접속하도록 허용하지 않는다.