프레임워크별
Django 보안 대책 — DEBUG·SECRET_KEY·인가 방어법
Django는 '배터리 포함'으로 안전한 기본값(ORM·CSRF·템플릿 자동 이스케이프)을 많이 갖추지만, 사고는 설정에서 일어납니다. 3대 = 운영 환경의 DEBUG=True(설정·시크릿 노출) / SECRET_KEY 누출 / 인가의 작업 부족. 더해 raw/extra의 SQLi, pickle의 위험. 기본값을 살리며 설정의 구멍을 막는 방법을 공격 절차는 빼고 풀어냅니다.
대상: Django로 앱을 운영하는 사람. 여기서는 공격 절차를 다루지 않고, 안전한 기본값을 살리면서, 설정에서 열리는 구멍을 막는 방법을 풀어냅니다. 전체 그림은 프레임워크별 보안의 입구도 참조하세요.
3대 함정(설정에서 열린다)
Django의 기본값은 우수하지만, 다음 3가지는 설정과 작업으로 지키는 영역입니다.
① 운영 환경의 DEBUG=True
오류 화면에 설정·환경 변수·시크릿이 노출. 고의 오류로 뽑힌다.
② SECRET_KEY의 누출
서명·세션·CSRF의 토대. 누출되면 위조·변조의 우려.
③ 인가의 부족
인증은 있지만 권한/소유자 확인 누락. ID 교체로 남의 데이터.
그 밖에 raw()/extra()나 문자열 결합에 의한 SQLi, pickle 등의 안전하지 않은 역직렬화, ALLOWED_HOSTS 미설정, 의존성(pip)의 알려진 CVE 방치도 주의점입니다.
막는 법(3스텝)
운영은 DEBUG=False + ALLOWED_HOSTS
ALLOWED_HOSTS를 올바르게 설정. 상세 오류의 외부 노출을 막고, 정적/미디어 배포도 운영용으로. 배포 절차에 넣어 매번 확인한다.SECRET_KEY를 환경에서·비공개로
SECRET_KEY는 코드/리포지토리에 두지 말고 환경 변수나 시크릿 매니저에서 읽어들인다. 공개 디렉터리나 DEBUG 화면에서 노출되지 않게 한다. 만일 누출되면 신속히 로테이션(→ 공개 디렉터리에 시크릿을 두지 않기).인가를 명시하고, 위험한 입력 경로를 끊는다
raw()의 문자열 결합을 피하고, 신뢰할 수 없는 데이터를 pickle로 복원하지 않는다. 의존성(pip)은 CVE 모니터링 + 즉시 패치(→ IDOR란).자주 하는(위험한)
- 운영을
DEBUG=True인 채로 SECRET_KEY를 코드/리포지토리에 직접 기재- 인가를 작성하지 않고 "로그인 = 열람 가능"
raw()의 문자열 결합·pickle로 복원
올바른
- 운영 DEBUG=False + ALLOWED_HOSTS
SECRET_KEY는 환경에서·비공개- 인가를 명시(권한/소유자 스코프)
- ORM/플레이스홀더·신뢰할 수 없는 복원을 피한다
본 사이트의 관점: 배터리 포함이라도 '설정과 인가'는 자신의 책임
Django는 많은 것을 기본값으로 지켜주지만, 운영의 설정(DEBUG/SECRET_KEY/ALLOWED_HOSTS)과 인가만은 환경마다·앱마다 직접 올바르게 정해야 합니다. 본 사이트가 반복해서 보는 사고도, 정교한 공격보다 "운영에서 디버그가 열려 있었다" "시크릿이 노출되어 있었다" "인가가 없었다"라는 설정·운영의 유형이 중심입니다. 그래서 방어의 무게 중심은 운영 설정을 죄고, 시크릿을 비공개로 지키고, 인가를 명시하는 것. 견고한 기본값을 망치지 않는 것이 Django 운영의 요점입니다.
다음으로 읽기
- 입구: 프레임워크별 보안(입구) / Laravel 보안 대책(운영 DEBUG·시크릿 노출이 가깝다)
- 시크릿: 공개 디렉터리에 시크릿을 두지 않기 / 실무: 취약점(CVE) 대응 실무
- 용어: IDOR란 / SQL 인젝션이란
FAQ
QDjango는 안전한 프레임워크인가요?
Django는 '배터리 포함' 사상으로 ORM에 의한 SQL 대책, CSRF 보호, 템플릿의 자동 이스케이프, 인증 기반 등을 표준으로 갖춥니다. 올바르게 설정하면 견고한 프레임워크지만, 사고는 본체가 아니라 설정에서 일어납니다. 특히 운영 환경의 DEBUG=True, SECRET_KEY의 누출, 인가의 작업 부족은 Django 고유라기보다 운영·설정의 문제로 반복해서 일어납니다.
Q운영 환경에서 DEBUG=True인 채로 두면 무엇이 위험한가요?
DEBUG가 켜져 있으면 오류 화면에 설정값·환경 변수·스택 트레이스 같은 내부 정보가 자세히 표시될 수 있습니다. 공격자는 일부러 오류를 일으켜 정보를 뽑아낼 수 있습니다. 운영 환경에서는 반드시 DEBUG=False로 하고 ALLOWED_HOSTS를 올바르게 설정하세요. 아울러 상세 오류의 외부 노출을 막고, 정적/미디어 배포 설정도 운영용으로 재검토합니다.
QSECRET_KEY는 왜 중요한가요?
SECRET_KEY는 서명된 쿠키나 세션, CSRF 토큰, 비밀번호 재설정 등의 토대가 되는 키입니다. 누출되면 이들의 위조나 변조로 이어질 수 있습니다. SECRET_KEY는 코드나 리포지토리에 두지 말고 환경 변수나 시크릿 매니저에서 읽어들이고, 만일 누출되면 신속히 로테이션하세요. 공개 디렉터리나 DEBUG 화면에서 노출되지 않게 하는 것도 중요합니다.