「Laravel 보안」「WordPress 하드닝」——검색할 때 우리는 '사용하는 기술마다' 답을 찾습니다. 이 페이지는 프레임워크별 방어법으로 들어가는 입구입니다(공격 절차는 싣지 않습니다).
공통(모든 프레임워크가 동일)
접근 제어·시크릿 관리·인젝션·의존성 CVE·설정 오류. 기본적인 방어도 공통.
프레임워크 고유(각 장에서 다룸)
'위험한 기본 설정'과 '그 기술에서 자주 노려지는 지점'. 기술마다 다른 것은 여기뿐.
모든 프레임워크에 공통되는 약점의 유형
먼저 전체 그림입니다. 아래는 기술을 가리지 않고 반복해서 노려지는 유형으로, 각 프레임워크 장은 이것이 그 기술에서 어떻게 드러나는지를 설명합니다.
프레임워크별 가이드
자신의 스택 장부터 읽으세요. 각 장은 '기본값의 위험 → 자주 노려지는 지점 → 하드닝 절차' 순입니다.
WordPress
Laravel
Next.js
Java / Spring
Express / Rails / Django / ASP.NET Core
운영 환경에서 먼저 확인할 설정(프레임워크별 한눈에 보는 표)
어떤 프레임워크든 먼저 두 가지를 확인합니다. 운영 환경에서 상세한 오류가 표시되는지, 그리고 시크릿이 어디에 있는지입니다. 설정 이름은 서로 다르므로 아래 표에서 자기 행을 찾으세요. 이름은 각 프로젝트의 현행 공식 문서와 대조했습니다(버전은 마지막 열).
| 프레임워크 | 상세 오류 화면 끄기 | 시크릿을 두는 곳과 주의점 | 놓치기 쉬운 설정 | 확인한 문서 |
|---|---|---|---|---|
| WordPress | wp-config.php에서 WP_DEBUG를 false로(기본값은 false) | DB 접속 정보는 wp-config.php에. 사본을 공개 디렉터리에 남기지 않는다 | 관리 화면에서의 파일 편집을 막는 DISALLOW_FILE_EDIT. 쓰지 않는 플러그인은 삭제 | Advanced Administration Handbook |
| Laravel | .env에서 APP_DEBUG=false | .env는 절대 커밋하지 않는다(암호화한 .env.encrypted는 괜찮다) | config:cache 뒤에는 설정 파일 밖의 env()가 아무것도 반환하지 않는다 | 13.x |
| Next.js | next build 후 next start로 실행. 개발 서버는 절대 공개하지 않는다 | NEXT_PUBLIC_ 변수는 브라우저용 JavaScript에 그대로 들어간다 | 시크릿에 NEXT_PUBLIC_ 접두사를 붙이는 실수 | 16.x |
| Spring Boot | 오류 응답에 스택 트레이스를 넣지 않는다(기본값 유지) | 설정에 직접 쓰지 말고 환경 변수로 넘긴다 | Actuator는 기본으로 health만 HTTP에 공개한다. management.endpoints.web.exposure.include=*는 절대 설정하지 않는다 | 4.1 |
| Django | DEBUG = False | SECRET_KEY는 환경 변수나 파일에서 읽고, 소스 관리에 넣지 않는다 | ALLOWED_HOSTS 설정. manage.py check --deploy 실행 | 6.1 |
| Ruby on Rails | 운영 환경 설정(config/environments/production.rb)을 쓴다 | config/credentials.yml.enc와 config/master.key. master.key는 절대 커밋하지 않는다 | HTTPS를 강제하는 config.force_ssl = true | 8.1 |
| Express | NODE_ENV=production이면 기본 오류 응답에서 스택 트레이스가 빠진다 | 코드가 아니라 환경 변수로 넘긴다 | 안전한 헤더를 위한 helmet, app.disable('x-powered-by') | 현행 공식 가이드 |
| ASP.NET Core | 개발자 예외 페이지는 Development 환경에서만 켜진다(현행 템플릿의 기본값) | 사용자 비밀(User secrets)은 개발용. 운영에서는 환경 변수나 키 자격 증명 모음을 쓴다 | ASPNETCORE_ENVIRONMENT를 Development로 둔 채 운영하지 않는다 | 10.0 |
실제 사례: 사고 대부분은 본체의 버그가 아니라 업데이트 누락과 운영 설정에서 나왔다
눈에 띄는 패턴은 프레임워크 결함 자체가 아니라, 수정판이 있었는데 적용하지 않았거나 개발용 설정이 운영 환경에 남아 있던 경우입니다.
- Equifax(2017년): Apache Struts 결함(CVE-2017-5638)의 수정판은 공개 당일에 나왔지만 공개 시스템에 적용되지 않았고, 약 1억 4,700만 명의 개인정보가 유출됐습니다(→ Equifax 유출 사고).
- Log4Shell(2021년): Java 로깅 라이브러리의 결함입니다. 많은 조직이 다른 구성 요소를 통해 이 라이브러리를 끌어들이고 있어, 쓰고 있는지조차 알 수 없었습니다(→ Log4Shell).
- AI 에이전트 사례(2026년): 연구용 AI 에이전트가 실제 웹사이트에 도달했을 때, 노출된 디버그 페이지에서 자격 증명이 읽혔고, 사이트는 알아차리지 못했습니다(→ 실제 웹사이트에 도달한 AI 에이전트).
OWASP Top 10(2025년)에서 1위는 접근 제어의 결함, 2위는 보안 설정 오류, 3위는 소프트웨어 공급망의 실패(의존하는 구성 요소의 문제)입니다. 모두 어떤 프레임워크에서든 일어납니다.
내 사이트를 확인하는 법
이 확인은 자신이 관리하는 사이트에서만 하세요.
존재하지 않는 URL을 열어 오류 화면을 본다
프레임워크 자체의 점검 명령을 쓴다
python manage.py check --deploy가 있고, Laravel은 php artisan about --only=environment로 디버그 모드를 보여 줍니다. Spring Boot라면 설정의 management.endpoints.web.exposure.include를 확인합니다.의존성과 외부에서 보이는 것을 스캔한다
npm audit, Composer면 composer audit, 모두 한꺼번에라면 osv-scanner를 씁니다(브라우저에서는 의존성 취약점 스캐너). 외부에서 보이는 것은 보안 헤더 점검으로 빠진 헤더를 확인하고, 사이트 보안 종합 점검으로 .env와 .git 노출, 인증서, 쿠키 플래그를 한 번에 확인합니다.흔한 실수와 고치는 법
| 흔한 실수 | 일어나는 일 | 고치는 법 |
|---|---|---|
비밀 API 키에 NEXT_PUBLIC_ 접두사를 붙인다 | 키가 브라우저용 JavaScript에 들어가 누구나 읽을 수 있다 | 접두사를 빼고 서버에서만 쓰며, 유출된 키는 발급처에서 폐기한다 |
| 모니터링 엔드포인트(Spring Boot Actuator 등)를 모두 공개한다 | 설정 값이나 메모리 내용을 외부에서 읽을 수 있다 | health 등만 공개하고, 나머지는 인증 뒤에 둔다 |
| 쓰지 않는 플러그인을 비활성화만 하고 남겨 둔다 | 파일이 서버에 남고 업데이트도 받지 않게 된다 | 쓰지 않는 것은 삭제한다 |
| 업데이트 알림을 읽고 적용됐는지 확인하지 않는다 | 수정판이 있는데도 구멍이 열린 채로 남는다(Equifax의 패턴) | 업데이트 뒤 버전을 확인하고, 의존성 스캔을 정기적으로 돌린다 |
본 사이트의 관점: 사고는 프레임워크 자체가 아니라 운영 방식에서 일어난다
「이 프레임워크는 안전/위험」이라는 논쟁은 별로 도움이 되지 않습니다. 실제 사고의 대부분은 본체의 버그가 아니라 업데이트 방치·시크릿 노출·인가 누락·위험한 기본 설정이라는 '사용법'에서 일어나기 때문입니다. 본 사이트 자신도 Next.js로 운영되고 있으며, 방어의 핵심은 특별한 것이 아니라 의존성 CVE 모니터링·시크릿을 코드나 공개 디렉터리에 두지 않기·강한 인증·되돌릴 수 있는 백업이라는 기초의 철저함입니다. 각 프레임워크 장은 이 기본을 그 기술에 맞춰 적용한 것입니다.
먼저 공통 기본을 갖춘다
프레임워크 장으로 나아가기 전에, 어떤 기술에서든 효과가 있는 기본을 먼저 갖춰 두면 효율적입니다.
- 입문: 보안 최소 체크리스트(관리자 계정·시크릿·패치·탐지·복구)
- 실무: 취약점(CVE) 대응 실무 · 의존성 CVE 모니터링(osv-scanner)
- 시크릿: 공개 디렉터리에 시크릿을 두지 않기
출처
- WordPress Advanced Administration Handbook, "Hardening WordPress" 및 "Debugging in WordPress" — developer.wordpress.org
- Laravel 13.x, "Configuration"(Environment File Security / Debug Mode) — laravel.com
- Next.js, "How to use environment variables in Next.js"(16.x) — nextjs.org
- Spring Boot 4.1, "Endpoints"(Actuator 공개 범위) — docs.spring.io
- Django 6.1, "Deployment checklist" — docs.djangoproject.com
- Ruby on Rails Guides, "Securing Rails Applications"(8.1) — guides.rubyonrails.org
- Express, "Production Best Practices: Security" 및 "Error Handling" — expressjs.com
- Microsoft Learn, "Handle errors in ASP.NET Core"(10.0) — learn.microsoft.com
- OWASP Top 10:2025 — top10.owasp.org
다음으로 읽기
- 가이드: WordPress 보안 대책 · Laravel 보안 대책
- 기본: 보안 최소 체크리스트(모든 프레임워크 공통)
- 용어: CVE란 무엇인가(프레임워크의 알려진 취약점을 추적하는 단위)