웹 디버깅 도구 Fiddler를 만들었고 인터넷 익스플로러, 엣지, 크롬 팀을 거치며 브라우저 보안을 오랫동안 다뤄온 베테랑 엔지니어 에릭 로렌스(Eric Lawrence)가 의미심장한 글을 올렸어요. 요지는 이래요. 웹을 안전하게 만들 수 있는 도구는 이미 다 나와 있는데, 그걸 '제대로' 쓰는 게 보통 개발자에게는 너무 어렵다는 거예요. 평생 브라우저 보안을 업으로 삼아온 사람이 '이건 너무 어렵다'고 말하는 거니까, 한 번쯤 귀 기울여볼 만하죠.
보안 기능은 많은데, 왜 사이트는 여전히 뚫릴까
대표적인 예가 CSP, 콘텐츠 보안 정책이에요. 이게 뭐냐면 '우리 사이트에서는 이 출처의 스크립트만 실행해도 된다'고 브라우저에게 알려주는 HTTP 헤더인데요, 제대로 설정하면 웹 공격의 고전인 XSS(사이트에 악성 스크립트를 심는 공격)를 상당 부분 원천 차단할 수 있는 강력한 도구예요. 그런데 현실은 어떨까요? 전체 웹사이트 중 CSP를 의미 있게 설정한 곳은 극소수예요. 설정 문법이 복잡하고, 외부 스크립트 하나만 추가해도 정책을 고쳐야 하고, 잘못 걸면 멀쩡한 기능이 죽어버리니까 다들 포기하거나 사실상 무력화된 설정으로 도망가거든요.
CORS도 비슷해요. 다른 출처의 리소스 접근을 통제하는 장치인데, 대부분의 개발자가 CORS를 처음 만나는 순간은 '콘솔에 뜬 빨간 에러를 없애야 할 때'예요. 그래서 검색으로 찾은 해결책을 복사해 붙이다가 모든 출처를 허용해버리는 설정을 넣곤 하죠. 보안 장치가 보호막이 아니라 '귀찮은 장애물'로 학습되는 거예요. 여기에 쿠키 하나만 해도 Secure, HttpOnly, SameSite 속성에 __Host- 접두사까지 알아야 하고, 그 위에 COOP·COEP 같은 격리 헤더, 서브리소스 무결성(SRI), Trusted Types까지... 알아야 할 목록이 끝이 없어요.
30년치 하위 호환성이 만든 구조적 문제
왜 이렇게 됐을까요? 웹은 태생부터 '기존에 돌아가던 것을 깨면 안 된다'는 원칙 위에서 진화해왔어요. 그래서 새로운 보안 기능은 기본으로 켜지 못하고, 개발자가 일부러 선택해서 켜야 하는 '옵트인' 방식으로 하나씩 쌓여왔거든요. 30년간 이게 반복된 결과, 지금의 웹은 '기본 상태가 안전한' 플랫폼이 아니라 '전문가가 수십 개의 스위치를 정확히 조작해야만 안전해지는' 플랫폼이 됐어요. 개별 기능은 하나하나 다 합리적인데, 전체를 합쳐 놓으면 한 사람이 감당할 수 없는 복잡도가 되는 거죠. 보안 사고가 나면 우리는 개발자의 실수를 탓하지만, 정작 실수하기 쉽게 설계된 시스템의 책임은 잘 묻지 않아요.
그럼 어떻게 해야 할까
업계가 찾아가고 있는 현실적인 답은 '개발자 개인이 아니라 플랫폼과 프레임워크가 보안을 떠안는 것'이에요. 리액트가 기본으로 출력값을 이스케이프해서 XSS를 막아주는 것처럼, 개발자가 특별히 의식하지 않아도 안전한 길이 기본값이 되게 만드는 거죠. 브라우저 쪽도 서드파티 쿠키 제한이나 HTTPS 우선 접속처럼 기본값을 조금씩 안전한 방향으로 옮겨왔고요. 프레임워크의 기본 보호 장치를 일부러 끄는 코드, 이름부터 위험하다고 외치는 dangerouslySetInnerHTML 같은 API를 코드 리뷰에서 걸러내는 문화도 이 흐름의 일부예요.
한국 개발자에게 주는 시사점
이 글의 교훈은 '저걸 전부 외워라'가 아니에요. 오히려 반대로, 우선순위를 잡으라는 거예요. 주니어라면 일단 세 가지만 확실히 챙겨도 충분히 훌륭해요. 첫째, 세션 쿠키에는 HttpOnly와 SameSite를 꼭 걸 것. 둘째, 프레임워크가 기본으로 제공하는 이스케이프와 CSRF 보호를 함부로 끄지 말 것. 셋째, 사용자 입력을 HTML에 직접 꽂아넣는 코드를 항상 의심할 것. 그다음 여유가 생기면 CSP를 Report-Only 모드로 걸어보세요. 이건 정책 위반을 차단하지 않고 보고만 해주는 모드라서, 서비스를 깨뜨릴 걱정 없이 우리 사이트에 어떤 위반이 있는지 관찰하면서 시작할 수 있거든요. 보안 헤더 상태를 무료로 점검해주는 온라인 도구에 자기 서비스 도메인을 넣어보는 것도 좋은 출발점이에요.
마무리
한 줄로 정리하면, 웹 보안이 어려운 건 여러분이 부족해서가 아니라 웹이라는 플랫폼이 30년치 복잡도를 개발자 개인에게 떠넘겨왔기 때문이고, 그래서 '안전한 기본값'을 주는 도구를 고르는 안목이 점점 중요해진다는 거예요. 여러분 팀에서는 보안 설정을 누가, 어떻게 챙기고 있나요? CSP 도입에 성공하신 분이 있다면 경험담이 궁금해요.
🔗 출처: Hacker News