보안
.env 파일이 브라우저에서 그대로 열리는 이유와 막는 법
.env 파일에는 보통 DB 접속 정보, API 키, 결제 시크릿 키가 들어 있습니다. 로컬 개발에서는 문제없이 동작하지만, 배포 설정에 따라 이 파일이 그대로 웹에 공개되는 경우가 있습니다.
왜 노출되나
- 정적 사이트 배포 시 빌드 산출물 폴더에
.env가 실수로 포함된 경우 - 서버 설정에서 dotfile(점으로 시작하는 파일)에 대한 접근 차단이 빠진 경우
- Git 저장소를 통째로 배포 폴더로 쓰면서
.gitignore가 배포 시점엔 적용 안 되는 경우
5분 안에 직접 확인하는 방법
브라우저 주소창에 아래 형태로 직접 접속해봅니다. 200 응답과 함께 텍스트 내용이 보이면 노출된 것입니다.
| 확인 경로 | 기대 결과 |
|---|---|
https://내도메인/.env | 404 또는 접근 거부여야 정상 |
https://내도메인/.git/config | 404여야 정상 |
https://내도메인/.env.local | 404여야 정상 |
배포 플랫폼별 대응
Vercel/Netlify류 정적 배포: .env가 빌드 출력 폴더(dist, public 등) 안에 들어가지 않도록 하고, 빌드 전 .gitignore·배포 무시 목록에 포함시킵니다.
서버 직접 운영: Nginx/Apache 설정에서 점(.)으로 시작하는 파일 접근을 명시적으로 차단합니다.
404가 나와도 끝이 아닌 이유
/.env가 404여도 비밀값이 이미 브라우저 자바스크립트에 포함됐을 수 있습니다. Vite의 VITE_, Next.js의 NEXT_PUBLIC_처럼 공개용 접두사가 붙은 변수는 빌드할 때 클라이언트 번들에 들어갑니다. 이 접두사에는 분석용 공개 ID처럼 노출을 전제로 한 값만 두고, DB 비밀번호·서버 API 키·웹훅 시크릿은 서버 런타임에서만 읽어야 합니다.
| 점검 위치 | 찾아야 할 신호 | 판정 |
|---|---|---|
| 배포 산출물 | .env*, 백업 파일, 저장소 메타데이터 | 포함되면 출시 차단 |
| 브라우저 Network·Sources | 실제 비밀값 또는 비밀 변수명 주변의 값 | 클라이언트 번들에 있으면 교체 |
| 호스팅 설정 | Production·Preview·Development가 같은 운영 키 사용 | 환경별 최소 권한 키로 분리 |
| Git 기록 | 현재 파일은 삭제됐지만 과거 커밋에 값 존재 | 기록 정리보다 키 폐기·재발급 우선 |
노출을 발견했을 때의 복구 순서
- 노출된 키의 권한과 사용처를 확인하고 공급자 콘솔에서 즉시 폐기하거나 회전합니다.
- 새 키는 Production·Preview·Development별로 분리하고 각 환경에 필요한 최소 권한만 부여합니다.
- 파일·빌드 설정·공개 접두사 사용을 수정한 뒤 새 환경변수가 반영되도록 다시 배포합니다.
- 배포 URL과 자바스크립트 번들을 다시 확인하고, 로그에서 비정상 호출·과금·데이터 접근이 있었는지 조사합니다.
- 저장소 기록에 비밀값이 남아 있더라도 먼저 키를 폐기합니다. 기록 삭제만으로 이미 복사된 키를 무효화할 수는 없습니다.
중요 — 이미 노출된 적이 있다면 파일을 지우는 것만으로는 부족합니다. 그 안에 있던 키·비밀번호는 이미 유출된 것으로 간주하고 전부 재발급해야 합니다.
공식 참고 자료
- OWASP: 백업·미참조 파일의 민감정보 노출 점검
- Vercel 환경변수 관리 공식 문서 — 환경별 범위와 변경 후 재배포
- Vercel Sensitive Environment Variables 공식 문서
Vercel에 저장한 환경변수도 브라우저 번들을 확인하세요
.env 파일 자체가 404여도 NEXT_PUBLIC_이나 VITE_ 접두사의 값은 빌드된 자바스크립트에 포함될 수 있습니다. Vercel의 Production·Preview 환경 분리, Sensitive 설정, 재배포와 유출 키 교체 순서는 Vercel 환경변수 보안 체크리스트에서 이어서 확인하세요.