Blog

서론#

API 키를 코드에 직접 쓰면 안 된다는 말은 누구나 알고 있다.
그래서 많은 개발자들이 .env 파일을 사용한다.

하지만 여기서 한 가지 질문이 생긴다.

env를 쓰면 정말 안전해진 걸까?

env는 무엇을 해결해주는가#

env의 역할은 단순하다.

• 민감한 값은 코드에서 분리한다
• 환경별 값을 다르게 주입할 수 있게 한다
• Git 저장소에 비밀 정보를 남기지 않게 한다.

env를 쓰면 여전히 위험한 이유#

env에 값을 넣었다고 해서 자동으로 안전해지는 것은 아니다.

특히 Next.js에서는 NEXT_PUBLIC_이 붙은 환경 변수가
빌드 시점에 JavaScript 번들에 그대로 포함된다.

즉, 해당 값은 브라우저에서 실행되는 코드 안에 들어가며,
개발자 도구나 소스 보기만으로도 누구나 확인할 수 있다.

이 때문에 NEXT_PUBLIC_ 환경 변수는
“숨겨진 값”이 아니라 의도적으로 노출되는 값이다.

또한 다음과 같은 경로로도 유출될 수 있다.

• 빌드 결과물(JS 번들)에 포함됨
• 로그, 에러 메시지를 통해 노출됨

env는 값을 감춰주는 장치가 아니라
노출 범위를 어디까지 허용할지를 결정하는 장치다.

env에 들어 있다는 이유만으로
해당 값이 안전하다고 생각하는 것은 위험하다.

그렇다면 노출돼도 괜찮은 값이란 무엇인가#

프론트엔드에서 사용하는 일부 키들은
노출을 전제로 설계된 값들이다.

예를 들어 다음과 같은 특징을 가진 경우다.

• 읽기 전용이거나 제한된 권한만 가진다
• 서버에서 추가적인 권한 검증을 거친다
• 유출되더라도 직접적인 피해가 발생하지 않는다

이런 조건을 만족하지 않는 값이라면,
env에 있더라도 클라이언트에 두어서는 안 된다.

env를 써도 사고가 나는 이유#

실제 보안 사고의 많은 경우는
env를 쓰지 않아서가 아니라,
env를 과신해서 발생한다.

• 실수로 .env 파일을 커밋한 경우
• 클라이언트 번들에 비밀 키가 포함된 경우

.env는 보안을 지켜주는 도구가 아니라, 보안을 설계하는 기준을 분리해주는 도구다.

그래서 env는 보안인가?#

env 자체는 보안 기능이 아니다.

하지만 다음 조건을 만족할 때
env는 보안 설계의 일부가 된다.

• 노출돼도 괜찮은 값만 클라이언트에 둔다
• 비밀 키는 서버 환경에서만 사용한다

참고#

• Next.js 한글 문서