Laravel 앱의 .env가 온 세상에 읽혔다 — 가장 흔한 공유 호스팅 실수

공유 호스팅에서 실제로 일어나는 설정 오류를, 도메인과 값을 제거하고 교훈으로 바꾼 글이다. 이것은 남의 사이트를 찾는 이야기가 아니라 — 자기(또는 인계받은) 배포를 안전하게 하는 이야기다.

무슨 일이 일어나고 있었나

공유 호스트에서 많은 Laravel 앱이 이런 식으로 배치되어 있었다. 위험한 배치와 올바른 배치를 나란히 본다:

~/public_html/
└── app/          ← Laravel 전체(틀림)
    ├── .env      ← /app/.env 로 읽힘
    ├── .git/     ← clone으로 전체 히스토리 복원
    ├── vendor/  config/  storage/
    └── public/   ← 여기 있어야 할 유일한 것

~/laravel/app/    ← 본체는 웹 루트 바깥
├── .env  .git/   ← HTTP로 닿지 않음 = 안전
└── public/       ← 이것만 symlink로 노출
        └── index.php

외부에 200 OK를 반환하던 전형적 파일들:

세 단계 수정

1단계 — 응급 처치: 민감 파일을 HTTP 수준에서 차단

먼저 "더 새는 것"을 멈춘다. 되돌릴 수 있고 정상 페이지에 영향이 없다. public_html/.htaccess 맨 위에 거부 블록을 추가하라(방어용 설정 예시):

# === SECURITY BLOCK ===
# .env / .git 아래 모든 것을 404
RedirectMatch 404 (?i)/\.(env|git)(\..*)?(/|$)
 
# 백업, 덤프, 자격증명 파일 거부
<FilesMatch "(?i)\.(sql|sql\.gz|bak|old|swp|save|orig|tgz)$|^credentials\.json$|\.bk[._]">
    Require all denied
</FilesMatch>
 
# /<app>/storage/... 등 Laravel 내부가 보이는 경우
RedirectMatch 403 (?i)^/[^/]+/(storage|bootstrap/cache|config|database|resources|routes|tests|vendor)(/|$)
# === END ===

하지만 블랙리스트는 근본적으로 두더지잡기다. composer.lock을 잊을 것이고; 새 파일명이 새 구멍을 만든다. 최선의 응급 처치로 여기고, 진짜 수정은 3단계에 두라.

2단계 — 키 교체(봤다고 가정)

.htaccess로 차단한 뒤에도 시크릿은 이미 봤다고 다뤄라. 우선순위 순:

1. 외부 API 키(최우선, 즉시): 과금과 계정 탈취로 직결된다. OAuth CLIENT_SECRET, API 키, 클라우드 자격증명을 폐기 + 재발급하되 최소 권한으로 범위 한정.
2. OAuth 클라이언트 시크릿.
3. APP_KEY: 재생성하면 세션이 깨지고 암호화된 DB 컬럼을 복호화할 수 없게 될 수 있다 — 먼저 영향 범위를 점검하라.
4. 메일/SMTP, DB 자격증명.

3단계 — 구조 재배치: 본체를 도큐먼트 루트 바깥으로(진짜 수정)

각 앱을 이렇게 다시 배치하라:

# 1. 본체를 웹 루트 바깥으로 이동(같은 파일시스템 → mv는 즉시, 원자적)
mv ~/example/public_html/app  ~/example/app-laravel
 
# 2. 웹 루트에는 최소한의 부트스트랩만
mkdir -p ~/example/public_html/sub
cat > ~/example/public_html/sub/index.php <<'PHP'
<?php require __DIR__ . '/../../app-laravel/public/index.php';
PHP
# 3. Laravel public/.htaccess 복사, 정적 자산 symlink, config 캐시 클리어

이 형태에서는 .env, .git, vendor/가 애초에 웹 루트에 존재하지 않으니, .htaccess 규칙에 의존하지 않고 안전하다. 전체 절차는 공유 호스팅에서 .env를 공개 웹에서 떼어놓기에 있다.

"교과서에 없는" 함정

• 서브도메인 범위 문제: 등록된 서브도메인의 도큐먼트 루트를 symlink로 다른 트리에 재지정하면 따라가지 못하고 500을 반환할 수 있다. → 도큐먼트 루트를 실제 디렉터리로 유지하고, 그 안의 작은 index.php에서 절대 경로로 require하라(안정적인 "부트스트랩 리다이렉트" 형태).
• opcache가 깨진 상태를 기억함: opcache는 실패한 index.php 로드를 기억해, 재구축 후에도 계속 500을 반환할 수 있다. 최후 수단: 파일명을 바꿔라(entry.php 등).
• '미등록' 서브도메인 도큐먼트 루트가 부모를 통해 읽힘: https://sub.example/는 무효인데 https://example/sub/는 여전히 내용을 보여줄 수 있다 — 놓치기 쉬운 입구. 점검할 때 부모 도메인 경로도 차단하라.
• config/*.php의 하드코딩 시크릿: 공개 .git과 결합하면 히스토리가 모든 교체 이력을 드러낸다. 항상 env()를 거치고 폴백 기본값에 실제 값을 넣지 마라.

가장 큰 교훈: 이것은 "한 사람의 실수"가 아니다

초기 공유 호스팅 문화는 모든 것을 public_html 바로 아래 두었다. (public/만 노출하도록 기대하는) Laravel이 거기로 흘러들었고, 위험한 "프로젝트를 public_html/<app>/ 아래 두고 그 public/을 노출" 배치가 사실상의 표준이 됐다 — 벤더 자체 문서도 public_html 기반 예시를 쓰는데, 그게 상황을 악화시킨다. 그러니 경계심이 아니라 프로세스로 고쳐라:

다음으로 읽기

• 용어집: .env란 무엇인가 · CVE란 무엇인가
• 방어: 공유 호스팅에서 .env를 공개 웹에서 떼어놓기
• 사고: 탈취된 API 키가 부정 과금으로 청구된 사례(또 다른 유출 경로 — 런타임)