‘조용히 채굴 당하는 사이트’가 실제로 많다.

운영자는 ‘서버가 정상이라 문제 없다’고 생각하고

“사이트가 좀 느린가?” 정도만 느끼고 지나간다.

하지만 채굴은 서버가 아니라 클라이언트에서 실행된다.

. . .

최근에 제 서버에서 외부 스크립트 하나가 자동 차단되는 일이 있었습니다.
에러도 아니고, 버그도 아니고... 이유는 단순했습니다.

 

그 스크립트 안에 eval()이 들어 있었기 때문입니다.

 

많은 분들이 잘 모르지만, eval()은 웹 보안에서 가장 위험한 함수 중 하나입니다.

 

[ 왜 위험한가? ]

 

eval()은 문자열을 그대로 코드처럼 실행합니다.
즉, 누군가 문자열을 조작할 수 있는 지점이 있다면
임의의 자바스크립트 실행이 그대로 허용됩니다.

 

이건 XSS 공격의 대표적인 수단이고,
계정 탈취/세션 변조 같은 사고는 대부분 여기서 시작됩니다.

 

더 큰 문제는 이런 위험한 코드가
외부 SDK, 위젯, 광고 스크립트 안에 은근히 많이 들어 있다는 점입니다.

 

[ 그런데 똑같은 스크립트를 로드해도
어떤 사이트는 안전하고, 어떤 사이트는 바로 뚫립니다. ]

 

차이는 단 하나입니다.

 

CSP(Content-Security-Policy)를 적용하느냐, 하지 않느냐.

 

CSP를 강하게 적용하면,
설령 불량 스크립트가 유입되더라도 다음과 같은 것들이 자동으로 제한됩니다.

 

- eval()

- 외부 자바스크립트

- inline script

- 이벤트에 숨겨진 악성 코드

 

정책 설정 예시(헤더 기준):

Content-Security-Policy:
default-src 'self';
script-src 'self';
object-src 'none';
frame-ancestors 'none';

 

여기서 중요한 점은,
script-src에 'unsafe-inline'이나 'unsafe-eval' 같은 값을 “넣지 않는 것 자체”가
곧 inline 스크립트와 eval() 사용을 금지한다는 의미라는 점입니다.

 

즉, 위와 같이만 설정해도
대부분의 외부/임의 스크립트 실행이 차단되고,
실수로 섞인 악성 스크립트가 그대로 실행되는 상황을 크게 줄일 수 있습니다.

 

[ 반대로 CSP가 없는 사이트는? ]

 

쉽게 말하면…

 

누구든지 스크립트를 꽂아 넣을 수 있는 상태입니다.

 

- 알 수 없는 광고 코드
- 검증되지 않은 외부 스크립트
- 확장 프로그램이 끼워 넣는 기능
- 주소창만 바꿔서 실행되는 악성 코드
- 클릭/이미지/에러 등에 숨겨진 스크립트

이 모든 것들이 그대로 실행될 수 있습니다.

 

커뮤니티나 쇼핑몰처럼
로그인 상태가 오래 유지되는 사이트는 특히 위험합니다.

 

[ 결론 ]

 

최근에 외부 SDK 하나가 eval() 때문에
제 서버에서 자동으로 차단된 걸 보고,

 

"CSP가 없었다면?" 이라는 생각이 들었습니다.

 

웹 보안은 눈에 잘 보이지 않지만
한 번 뚫리면 복구가 거의 불가능합니다.

 

혹시 아직 CSP를 적용하지 않은 곳이 있다면
이 글을 계기로 한 번 검토해보시길 권합니다.

 

eval을 허용하지 마세요.
외부 스크립트를 신뢰하지 마세요.
CSP는 선택이 아니라 기본 보안입니다.

 

(붙임)
브라우저 개발자도구(F12)의 Lighthouse는
단순히 디자인이나 속도만 보는 도구가 아니라
보안 헤더, TLS, 압축, 캐싱, 리소스 처리까지
예상보다 깊은 레벨로 검사합니다.
생각보다 쓸 만한 “서버 헬스 체크 도구”(私見)로도 활용할 수 있습니다.

( 실무에서 CSP를 제대로 적용하는 경우는 체감상 10% 이하일 겁니다 )

 

- 💫glitter0gim