Web Push에서 “누가 보냈는가”와 “무슨 내용을 보냈는가”는 같은 보안 문제가 아닙니다. VAPID는 애플리케이션 서버가 푸시 서비스에 자신을 식별하는 방식이고, RFC 8291은 푸시 본문을 사용자 에이전트가 복호화할 수 있도록 보호합니다. 알림 표시 권한도 이 둘과 다른 조건입니다.

VAPID 발신자 확인과 RFC 8291 페이로드 암호화를 별도 경계로 보여 주는 Web Push 개념도

발신 서버를 식별하는 VAPID

웹 애플리케이션 서버는 구독 정보를 이용해 push service로 메시지 전송을 요청합니다. RFC 8292의 VAPID는 서명된 토큰과 공개 키를 통해 요청 발신자의 애플리케이션 서버 키를 식별하는 선택적 인증 체계입니다. push service는 이를 요청 주체를 구분하거나, 구독을 특정 서버 키에 묶는 데 사용할 수 있습니다.

이는 사용자에게 보이는 발신자 이름을 인증한다는 뜻이 아닙니다. 서명은 요청과 애플리케이션 서버 키의 관계를 보여 줄 뿐, 메시지 내용의 진실성이나 운영자의 법적 신원을 증명하지 않습니다. 토큰에 연락처를 넣어도 그 정보는 운영자가 제공한 주장입니다. 서버 키의 분실이나 교체가 구독에 영향을 줄 수 있어 키 보관·교체도 운영 설계에 포함해야 합니다.

RFC 8291은 본문을 따로 암호화한다

VAPID가 발신 요청을 식별해도 본문은 저절로 암호화되지 않습니다. 구독 때 사용자 에이전트가 만든 공개 키와 서버가 전송마다 만드는 키 재료를 사용합니다. RFC 8291은 P-256 곡선의 ECDH 키 합의와 키 유도 절차를 정하고, 파생한 대칭 키와 nonce로 페이로드를 암호화합니다.

이 절차는 push service가 보호된 본문을 읽거나 바꾸기 어렵게 하는 것이 목적입니다. 그렇다고 전달에 필요한 endpoint와 시점 같은 메타데이터까지 모두 숨기지는 않습니다. 암호화는 브라우저에 알림을 표시하라는 지시도 아닙니다. 본문 기밀성과 서비스에 남을 수 있는 전달 정보를 구분해 설명해야 합니다.

구독과 표시 권한은 별도 상태다

사용자가 알림을 허용하고 사이트가 Push API 구독을 만들면, 브라우저는 push service와 연결된 endpoint와 암호화 자료를 돌려줍니다. 서버는 구독을 저장하고 요청을 서명해 보냅니다. 서비스 워커는 브라우저가 전달한 push 이벤트를 처리하고, 필요한 경우 알림을 표시합니다.

구독은 전송 대상을 가리키는 데이터이고, 권한은 알림을 받을 수 있도록 허용했는지에 관한 브라우저 상태입니다. 권한이 거부되거나 구독이 취소·만료되면 서버 키와 암호화가 올바르더라도 원하는 결과를 얻지 못할 수 있습니다. endpoint와 구독 키는 운영상 민감한 데이터로 다루고 로그에 노출하지 않으며, 쓸모없어진 구독을 정리해야 합니다.

전달은 보안 규격이 약속하는 결과가 아니다

Web Push는 서버가 메시지를 제출하고 브라우저가 이를 처리할 수 있게 합니다. 단말이 오프라인일 때 언제 받을지, 브라우저가 백그라운드에서 실행될지, OS가 알림을 보여 줄지는 보장하지 않습니다. 네트워크, 만료 설정, 브라우저 정책, 사용자 설정, 전원 관리가 결과에 영향을 줍니다. 요청 성공 응답은 사람이 알림을 읽었다는 증거가 아닙니다.

민감한 내용을 잠금 화면이나 공유 기기에서 노출할 수 있는지도 살펴야 합니다. 본문에는 필요한 정보만 두고 상세 내용은 인증된 화면에서 확인하게 하는 설계가 노출을 줄일 수 있습니다. 이는 RFC가 요구하는 UX가 아니라 정보 민감도와 사용 환경에 따른 운영 판단입니다.

세 경계에 맞춰 구현을 점검한다

리뷰에서는 먼저 VAPID 키가 어떤 서버를 식별하고 어떤 구독에 연결되는지 확인합니다. 다음으로 본문이 RFC 8291 방식으로 암호화되는지, push service에 어떤 전달 정보가 보이는지 묻습니다. 마지막으로 권한 변경, 구독 갱신·해지, 서비스 워커 실패와 알림 표시를 점검합니다.

인증 실패는 토큰·키·구독 연결을, 복호화 오류는 구독 키와 암호문 구성을, 화면에 알림이 나오지 않는 문제는 권한·서비스 워커·브라우저 동작을 살펴야 합니다. 이 경로들을 각각 시험하면 한 계층의 성공을 다른 계층의 성공으로 오해하지 않습니다. 한 브라우저에서의 전송 성공을 모든 기기의 백그라운드 전달 보장으로 일반화하지 않는 것이 핵심입니다.

전문가 관점에서 web.dev의 구현 해설은 브라우저 구독 키와 애플리케이션 서버 키가 서로 다른 용도임을 보여 줍니다. 운영자는 “Web Push 키” 하나로 뭉뚱그리지 말고 키가 만들어지고 저장·교체되는 경로를 각각 검토해야 합니다.

참고 자료