프레임워크별
Laravel 보안 대책 — .env 노출·APP_DEBUG·인가의 방어법
Laravel은 기본값이 비교적 안전하지만 사고는 운영에서 일어납니다. 3대 문제는 '.env나 시크릿의 공개 디렉터리 노출' '운영 환경의 APP_DEBUG=true' '인가 누락(인증≠인가·Mass Assignment)'. 시크릿을 public 밖으로·운영 환경은 디버그 비활성화·Policy/Gate로 인가·$fillable로 지키는 최소한의 대책을, 공격 절차는 빼고 풀어냅니다.
대상: Laravel로 앱을 운영하는 사람. 여기서는 공격 절차를 다루지 않고, 운영에서 일어나는 3대 사고와 그 막는 법을 풀어냅니다. 전체 그림은 프레임워크별 보안 입구도 참고하세요.
3대 함정(기본값이 지켜주지 않는 곳)
Laravel의 이스케이프나 인증은 우수하지만, 다음 세 가지는 개발자가 스스로 막는 영역입니다.
① 시크릿의 공개 노출
.env·백업·키가 public/에서 URL로 가져와짐. 배치 실수로 즉시 유출.
② 운영 환경의 디버그 활성화
APP_DEBUG=true로 에러 화면에 환경 변수·접속 정보가 노출. 고의의 에러로 빼내진다.
③ 인가 누락
인증은 있지만 소유자 스코프 없음(IDOR) / Mass Assignment로 is_admin 등을 덮어쓰기.
막는 법(3단계)
시크릿을 공개 디렉터리 밖으로(권한 600)
.env를 도큐먼트 루트 밖에 두는 구성이지만, 백업·익스포트·키 파일을 실수로 public/에 두지 마세요. 시크릿은 앱 루트 밖에, 권한 600(소유자만). (→ 공개 디렉터리에 시크릿을 두지 않기 · .env 전면 공개 사례)운영 환경은 디버그 비활성화 + 설정 캐시
APP_DEBUG=false·APP_ENV=production을 확실히. 설정 캐시로 반영을 고정하고, 상세 에러의 외부 노출을 막으세요. 배포 절차에 넣고 매번 확인합니다.인가를 구현한다(Policy/Gate + $fillable)
$fillable을 명시해 의도치 않은 필드의 덮어쓰기를 막습니다. (→ IDOR이란 무엇인가)흔히 하는(위험)
- 백업이나 키를
public/에 두어 URL로 도달 - 운영 환경을
APP_DEBUG=true인 채 운영 - 인가를 만들지 않고 「로그인=열람 가능」
Model::create($request->all())로 모든 필드 수용
올바른
- 시크릿은 도큐먼트 루트 밖·권한 600
- 운영 환경 디버그 비활성화 + 설정 캐시
- Policy/Gate로 소유자 스코프
$fillable명시로 Mass Assignment 차단
본 사이트의 관점: 견고한 것은 기본값까지, 인가는 자신의 책임
Laravel은 좋은 기본값을 많이 가지고 있지만, 「누가·무엇을·해도 되는가」라는 인가만큼은 앱 고유이므로 프레임워크가 자동으로 지켜줄 수 없습니다. 본 사이트가 반복해서 봐온 사고도, SQLi나 XSS보다 「인증은 있는데 소유자 검사가 없는」 유형이 많습니다. 그래서 방어의 무게 중심은 화려한 설정보다 「조회·수정할 때마다 소유자로 스코프하는」 수수한 구현에 있습니다. 아울러 시크릿을 공개 표면에서 떼어내고, 운영 환경의 디버그를 끄는 것 — 이 세 가지로 Laravel의 실운영 사고 대부분은 막을 수 있습니다.
다음으로 읽기
- 입구: 프레임워크별 보안 · WordPress 보안 대책
- 시크릿: 공개 디렉터리에 시크릿을 두지 않기 · 사례: .env 전면 공개 사례
- 인가: IDOR이란 무엇인가 · 실무: 취약점(CVE) 대응 실무
FAQ
QLaravel은 안전한 프레임워크인가요?
Laravel은 이스케이프나 인증 등 안전한 기본값을 많이 갖추고 있어, 기본 상태에서는 비교적 견고한 프레임워크입니다. 하지만 '기본값이 안전하다'와 '운영이 안전하다'는 별개의 문제이고, 실제 사고는 본체의 버그가 아니라 설정·운영에서 일어납니다. 특히 .env나 시크릿의 노출, 운영 환경에서의 디버그 활성화, 인가의 구현 부족은 프레임워크가 대신 지켜주지 않는 영역입니다. 기본값에만 기대지 말고, 이 세 가지를 스스로 막아야 합니다.
QAPP_DEBUG=true인 채 운영 환경에 내보내면 무엇이 위험한가요?
디버그가 활성화되어 있으면, 에러 발생 시 화면에 스택 트레이스뿐 아니라 환경 변수나 접속 정보 같은 내부 기밀이 표시될 수 있습니다. 공격자는 일부러 에러를 일으켜 정보를 빼낼 수 있습니다. 운영 환경에서는 반드시 APP_DEBUG=false로 하고, 설정을 캐시(config cache)해 확실히 반영시키세요. 아울러 상세 에러의 외부 노출도 막습니다.
Q'로그인해 있으면 볼 수 있다'는 상태는 왜 위험한가요?
그것은 '인증'은 있지만 '인가'가 없는 상태입니다. 로그인했더라도 그 데이터가 정말 그 사용자의 것인지를 user_id 등으로 스코프하지 않으면, URL의 ID를 바꾸는 것만으로 타인의 데이터가 보일 수 있습니다(IDOR). Laravel에서는 Policy / Gate로 소유자 검사를 구현하고, Mass Assignment는 $fillable을 명시해 의도치 않은 필드의 덮어쓰기를 막습니다.