"보안이 중요하다는 말은 계속 듣는데, 대체 어디서 시작하지?" 이것이 인디 개발자를 위한 가장 첫걸음이다. 겁주려는 게 아니라 — 오늘 실천할 수 있는 것만, 순서대로.
왜 "시크릿"부터인가
실제 사고 대부분은 정교한 공격이 아니라 유출된 시크릿에서 시작된다. 본 사이트가 토대로 삼는 두 사례는 모두 시크릿 유출이었다:
시크릿을 지키면 흔한 사고 대부분을 막는다. 그래서 여기서 시작한다.
.env란 무엇인가 (30초)
.env는 앱의 시크릿 값을 모아둔 파일이다: 데이터베이스 비밀번호, 외부 API 키, 세션을 암호화하는 키. 키들이 한 파일에 함께 있으니, 한 번 유출되면 전부 한꺼번에 새어 나간다 — 그래서 가장 먼저 지켜야 할 파일이다(→ 용어집: .env란 무엇인가).
API 키 유출이 뜻하는 것
API 키는 "서비스를 당신으로서 쓰는 여분 열쇠" 다. 잘못된 손에 들어가면 이렇게 연쇄한다.
탈취된 키는 흔히 재판매되어 시간차를 두고 악용된다 — "처음엔 아무 일 없다가, 어느 날 갑작스러운 청구서"가 전형적 패턴이다. 그러니 "알아챈 뒤"는 너무 늦다. 핵심은 애초에 유출하지 않는 것이다.
오늘 시작할 네 가지 습관
어려운 것 없다. 이 넷뿐이다.
노출하지 마라
.env나 앱 본체를 웹에서 보이는 디렉터리(웹 루트)에 두지 마라. public/ 만 노출하라. 공유 호스팅용 구체적 절차: 이 가이드.
커밋하지 마라
.env* 를 .gitignore에 추가하고(!.env.example은 허용); 값이 없는 예시만 공유하라. 한 번 커밋되면 히스토리에서 복원되니, 처음부터 빼두라.
유출되면 전부 교체하라
키 하나만이 아니라 — 유출됐을 수 있는 모든 시크릿을 교체하라. 순서: 외부 API / OAuth → 암호화 키 → 메일 → DB. 본 것처럼 행동하라.
스스로 점검하라
가끔 /.env가 외부에서 열리지 않는지 확인하라(아래).
자가 점검(자신이 소유한 도메인에 대해서만)
# 본문이 있는 200이면 노출된 것. 403/404면 일단 괜찮음.
curl -sI https://your-domain/.env | head -1
curl -sI https://your-domain/.git/config | head -1배포할 때마다 이걸 확인하면 배치 실수를 일찍 잡는다.
흔한 실수 vs 올바른 첫걸음
흔함
- "되니까",
.env를 public 바로 아래 둠 - "나중에 지우지",
.env를 한 번 커밋함 - 악용을 본 키 하나만 교체
올바른 첫걸음
- 앱 본체를 웹 루트 바깥에,
public/만 노출 - 처음부터
.gitignore로.env제외 - 유출되면 환경의 모든 시크릿 교체
다음 단계
여기서부터 다음 주제는 "내 스택의 위험한 기본값"과 "공개된 CVE에 뒤처지지 않는 시스템"이다. 서두르지 말고, 하나씩.
다음으로 읽기
- 용어집: .env란 무엇인가 · CVE란 무엇인가 · RCE란 무엇인가
- 방어: .env를 공개 웹에서 떼어놓기 · Next.js CVE 위생
- 사고: 탈취된 API 키가 부정 과금으로 청구된 사례
- 사고: 탈취된 키로 계정이 정지된 사례
FAQ
Q보안은 어디서부터 시작해야 하나요?
시크릿(.env와 API 키)을 유출하지 않는 것부터입니다. 실제 사고 대부분이 거기서 시작됩니다. 노출하지 말고, git에 커밋하지 말고, 유출되면 전부 교체하고, 가끔 스스로 점검하세요 — 그러면 대부분을 막습니다.
QAPI 키가 유출되면 구체적으로 무슨 일이 일어나나요?
누군가 외부 서비스에 대해 당신처럼 행동할 수 있습니다. 흔한 결과는 부정 과금(과도한 사용량이 당신에게 청구됨)과 데이터 읽기/쓰기입니다. 탈취된 키는 흔히 재판매되어 시간차를 두고 악용됩니다.
Q.env를 git에 넣어도 되나요?
안 됩니다. .env* 를 .gitignore에 추가하고 값이 없는 .env.example만 공유하세요. 한 번 커밋되면, 나중에 지워도 git 히스토리에서 복원될 수 있습니다.