공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라

대상: 공유/임대 호스팅이나 VPS에서 여러 사이트를 운영하며 공개 디렉터리(public/, public_html/, htdocs/ 등)로 배포하는 모든 사람. 공격 절차는 없습니다 — 오직 자기 서버를 점검해 문제를 막는 것뿐입니다. .env 자체를 보호하는 법은 공유 호스팅에서 .env 보호하기를 보세요.

"공개 디렉터리의 잔여물"이 생기는 이유

흔한 패턴은 편의상 둔 파일, 혹은 보일러플레이트 안에 딸려 온 파일이 조용히 공개된 채 남는 것입니다.

예를 들어 제3자 연동용 액세스 토큰을 담은 JSON이 public/ 아래에 오래 놓여 있고 — 공유 템플릿에서 왔다면 같은 파일이 많은 사이트의 같은 자리에 복사되어 모두 같은 문제를 갖습니다. 한 사이트만 고쳐도 다른 사이트에 파일이 남아 있으면 무의미합니다. 똑같이 위험한 것: 남겨진 .env, 데이터베이스 백업(.sql), .git 디렉터리, 에디터 백업(*.bak), 단축 파일(관련: 경로 순회 · .env 전체가 노출됨).

남겨지기 쉬운 파일과 각각이 위험한 이유

"시크릿 파일" 하면 보통 .env를 떠올리지만, 실제로 남겨지는 것은 훨씬 다양합니다. 웹 보안을 다루는 비영리 단체 OWASP의 테스트 가이드도 파일의 이전 버전, 백업, 어디서도 링크되지 않은 파일을 점검 대상으로 꼽습니다.

마지막 행은 놓치기 쉽습니다. 파일을 직접 두지 않았더라도 빌드가 시크릿을 공개 디렉터리로 밀어 넣을 수 있습니다. Vite 공식 문서는 VITE_ 변수에 API 키 같은 민감한 정보를 넣으면 안 된다고 분명히 적고 있습니다.

자기 서버를 점검하라

먼저 "내 공개 디렉터리에 시크릿 같은 파일이 있는가"를 기계적으로 드러내세요. 이는 자기 자산을 점검하는 것이지 남의 사이트를 엿보는 것이 아닙니다.

# audit under your own public directories (inspecting your own assets)
find ~ -path '*/public/*' \( -iname '*token*.json' -o -iname '*credential*.json' \
      -o -iname '*.bak' -o -iname '*.sql' -o -iname '.env*' \) 2>/dev/null
# an exposed .git directory is dangerous too
find ~ -path '*/public/*/.git' -maxdepth 8 2>/dev/null

내 환경을 점검하는 법

위의 find는 출발점입니다. 아래 다섯 가지 점검을 차례로 하면 파일 이름 검색만으로는 놓치는 잔여물까지 잡을 수 있습니다. 반드시 자기 서버와 자기 도메인에만 실행하세요. .env에 특화된 점검(응답의 첫 바이트 확인, .htaccess가 실제로 작동하는지 확인)은 공유 호스팅에서 .env 보호하기에서 다룹니다.

찾았을 때 할 일

세 가지를 한 묶음으로 하세요 — 제거, 폐기, 이동. 하나라도 빠뜨리면 대응이 완전하지 않습니다.

서버별: 이런 파일의 서빙을 거부하는 설정(보조 수단으로)

진짜 해결책은 파일을 거기 두지 않는 것입니다. 그 위에, 실수로 둔 것도 서빙되지 않도록 웹 서버에 거부 규칙을 더하세요. 쓸 수 있는 방법은 환경에 따라 다릅니다.

Apache 예시(.htaccess가 활성화된 경우):

Options -Indexes
<FilesMatch "(^\.|~$|\.(bak|old|orig|swp|sql|zip|tar|gz|pem|key)$)">
    Require all denied
</FilesMatch>

Nginx 예시(server 블록 안):

# Allow the path used for automatic certificate renewal (Let's Encrypt) first
location ^~ /.well-known/acme-challenge/ { }
 
# Deny files and directories starting with a dot (.env, .git, ...)
location ~ /\. { deny all; }
 
# Deny backups and archives
location ~* (~|\.(bak|old|orig|swp|sql|zip|tar|gz|pem|key))$ { deny all; }

Nginx에서는 요청이 ^~가 붙은 location과 일치하면 정규식 location은 확인하지 않습니다. 그래서 점으로 시작하는 경로를 거부하는 규칙이 있어도 인증서 갱신에 쓰이는 /.well-known/acme-challenge/는 계속 서빙됩니다. 설정을 바꾼 뒤에는 nginx -t로 문법을 확인하고, 다시 불러온 다음, 더미 파일이 403을 반환하는지 확인하세요. 사이트에서 ZIP 파일 등을 다운로드로 제공한다면 그 확장자는 거부 목록에서 빼세요.

흔한 실수와 고치는 법

• 거부 규칙에 의존하고 파일은 그대로 둔다: 서버 이전이나 설정 재작성으로 규칙이 빠지면 그날부터 파일이 공개됩니다. Nginx는 .htaccess를 전혀 읽지 않습니다. 규칙은 보조 수단으로 보고, 파일을 공개 디렉터리 밖으로 옮기세요.
• 운영 서버에서 파일을 직접 편집한다: 에디터가 ~나 .swp로 끝나는 백업을 남깁니다. OWASP 테스트 가이드도 웹 서버에서 파일을 직접 편집하지 말라고 권합니다. 로컬에서 편집하고 배포를 통해 반영하세요.
• 프로젝트 폴더 전체를 공개 디렉터리에 복사한다: .env, .git, 테스트 데이터가 함께 나갑니다. 빌드 결과물 폴더만 서빙하고, 복사할 대상을 정확히 지정하세요.
• 점으로 시작하는 경로를 모두 거부해 인증서 갱신이 깨진다: Let's Encrypt는 확인용 파일을 /.well-known/acme-challenge/ 아래에 둡니다. 위의 Nginx 예시처럼 그 경로를 먼저 허용하세요.
• VITE_나 NEXT_PUBLIC_ 변수에 시크릿을 넣는다: 빌드된 JavaScript에 삽입되어 누구나 읽을 수 있습니다. 서버 측 코드에서만 쓰고, 이미 이렇게 배포한 키는 폐기하세요.
• 파일을 삭제하고 거기서 멈춘다: 검색 엔진이 색인했다면 결과에 남아 있을 수 있습니다. URL이 404나 410을 반환하는지 확인한 뒤, 재크롤링으로 사라질 때까지 Google Search Console의 삭제 도구로 일시적으로(약 6개월) 숨기세요.

실제 사례: 공개 보고서에 숨어 있던 개인정보

워싱턴 D.C.에서 Medicaid(저소득층을 위한 공적 의료보험)를 운영하는 보건의료재정국(DHCF)은, 2023년부터 2026년 7월까지 웹사이트에 게시한 통계 보고서 두 건에 원본 개인정보가 "숨겨진 필드"로 들어 있었다고 밝혔습니다. 보고서는 집계 수치만 보이도록 만들어졌지만, 파일에는 수급자의 Medicaid 번호, 생년월일 등이 남아 있었습니다. 미국 보건복지부(HHS)에 제출한 신고에서 피해자 수는 399,086명이었습니다. DHCF는 2026년 7월 21일 이 문제를 알게 되어 보고서를 내렸습니다.

잊힌 시크릿 파일 사례는 아니지만, 뿌리는 같습니다.

• 공개 디렉터리의 파일은 화면에 보이는 부분만이 아니라 통째로 가져갈 수 있다
• 게시자가 "보이지 않는다"고 생각하는 정보가 검토에서 가장 놓치기 쉽다
• 누군가 알아채기까지 몇 년 동안 게시된 채로 남을 수 있다

게시 전에 "이 파일 안에 실제로 무엇이 들어 있는가"를 확인하는 단계가 잔여 파일과 숨은 데이터를 모두 막습니다. 전체 경위는 워싱턴 D.C. Medicaid 데이터 노출(영문)에 있습니다.

본 사이트는 직접 어떻게 하는가

본 사이트의 기본 원칙은 시크릿 — 키, 토큰, 접속 문자열 — 을 공개 디렉터리와 코드 저장소 양쪽에서 빼두는 것입니다. 배포 산출물에는 빌드된 공개 에셋만 들어가고, 시크릿은 서빙되지 않는 곳에 런타임 환경 변수로 보관합니다. 이유는: 이 글의 사고 부류가, 남겨진 파일 하나가 그 URL을 요청한 누구에게나 전부를 유출하는 전형적인 사례이기 때문입니다. 우리는 배치 자체를 접근 제어로 설계하고, 이 점검을 취약점 대응 인벤토리와 같은 주기로 돌립니다.

다음으로 읽기

• 스택: 공유 호스팅에서 .env 보호하기 · 취약점 대응 플레이북(인벤토리)
• 용어집: .env 파일과 시크릿 · 경로 순회
• 사고: .env 전체가 노출됨
• 보관: 시크릿을 안전하게 보관하기
• 클라우드에서: 공개 버킷(영문)(서버 밖에서 일어나는 같은 문제)
• 업체가 침해되었을 때: 웹 호스팅 업체가 침해되었을 때 할 일(영문)(거기 있던 것은 읽혔다고 가정)
• 실제 사례: 공개 보고서에 남은 Medicaid 번호(워싱턴 D.C., 영문)(공개 파일이 통째로 노출됨)

출처

• IPA, 「안전한 웹사이트 운영 관리를 위한 20가지 점검 포인트」(일본어; 공개하면 안 되는 파일, 검색 엔진 캐시): ipa.go.jp
• OWASP, "Web Security Testing Guide: Review Old Backup and Unreferenced Files for Sensitive Information"(.old, ~, .swp 백업; 서버에서 직접 편집하지 말 것): wstg.owasp.org
• Apache HTTP Server 2.4, "Upgrading to 2.4 from 2.2"(AllowOverride의 기본값은 None) 및 "mod_autoindex"(Options +Indexes가 목록을 생성): httpd.apache.org, httpd.apache.org
• nginx, "ngx_http_core_module: location"(일치 순서와 ^~) 및 "ngx_http_autoindex_module"(autoindex의 기본값은 off): nginx.org, nginx.org
• Let's Encrypt, "Challenge Types"(HTTP-01은 /.well-known/acme-challenge/를 사용): letsencrypt.org
• Vite, "Env Variables and Modes"(VITE_ 변수는 클라이언트 코드에 노출됨): vite.dev
• Next.js, "Environment Variables"(NEXT_PUBLIC_ 변수는 브라우저용 JavaScript에 삽입됨): nextjs.org
• Google Search Console 고객센터, "Removals tool"(일시 삭제는 약 6개월 유지): support.google.com
• District of Columbia DHCF, "Notice of Data Incident": dhcf.dc.gov; HIPAA Journal(HHS에 보고된 인원): hipaajournal.com