프레임워크별
Spring Boot 보안 — 프로덕션 하드닝 실무 레퍼런스
Spring Boot를 안전하게 운영하기 위한 프로덕션 하드닝 레퍼런스. 우선순위 체크리스트에 더해 의존성 CVE(Log4Shell)·프로덕션 설정과 시크릿·Spring Security 인가·Actuator 노출·역직렬화·SSRF까지. 방어 중심, 공격 절차는 다루지 않습니다.
대상: Java / Spring Boot로 앱을 운영하는 사람. 여기서는 공격 절차를 다루지 않고, 프로덕션을 다지기 위한 실무 레퍼런스(우선순위 체크리스트·영역별 대책·자기 검증)를 제시합니다. 프레임워크 전반의 그림은 프레임워크별 보안 입구도 참고하세요.
우선순위 순 하드닝 체크리스트
이 표를 위에서부터 실행하세요. P0는 전제, P1은 가장 잦은 사고원, P2는 지속적인 운영 위생입니다.
P0 ── 전제(먼저 이것)
의존성 CVE 모니터링 + 빠른 패치 / 프로덕션에서 에러 상세 미노출 / 시크릿 외부화
P1 ── 최다 사고원
Spring Security 인가(기본 거부·소유자 검사) / Actuator·관리 노출 축소
P2 ── 운영 위생
안전하지 않은 역직렬화 / 헤더·CSRF·세션 / SSRF
| 우선순위 | 대책 | 구체(Spring Boot) |
|---|---|---|
| P0 | 의존성 CVE 모니터링 | osv-scanner / dependency-check로 감시·가동 중인 버전으로 판단하고 빠르게 패치(Log4Shell급) |
| P0 | 프로덕션 에러 | 스택 트레이스를 외부에 노출하지 않기(server.error.include-stacktrace=never 등) |
| P0 | 시크릿 외부화 | 접속 정보/키를 하드코딩하지 말고 env/Vault에서. 저장소에 커밋하지 않기 |
| P1 | 인가를 명시 | 기본 거부 + 메서드 인가(@PreAuthorize) + 소유자 검사 |
| P1 | Actuator 노출 축소 | 최소 노출(예: health) + 인증 필수 + 별도 포트/경계. env/heapdump 노출 금지 |
| P1 | 역직렬화 | 신뢰할 수 없는 데이터를 네이티브 역직렬화하지 않기. SpEL이 입력을 평가하게 두지 않기 |
| P2 | 인젝션 | JPA/JdbcTemplate로 바인딩. 문자열 연결로 쿼리를 만들지 않기 |
| P2 | 헤더/CSRF/세션 | Spring Security 헤더(HSTS 등)·CSRF·쿠키 속성·세션 고정 대책 |
| P2 | SSRF | 서버 측 외부 요청은 허용 목록으로 제한 + 내부 IP/메타데이터 차단 |
1. 의존성 CVE와 에코시스템 (P0)
Spring은 널리 쓰이기 때문에 바로 의존성 라이브러리의 결함이 모두에게 한꺼번에 파급됩니다. Log4Shell은 그 상징입니다.
- 의존성 CVE를 osv-scanner나 OWASP dependency-check로 기계 모니터링하고, 가동 중인 버전으로 판단해 빠르게 패치하세요(pom.xml/gradle의 선언이 아니라 실제로 빌드된 버전으로 판단).
- Spring Boot와 Java를 지원 버전으로 유지하세요. EOL 버전을 방치하지 마세요.
- 사례와 실무는 Log4Shell 해부 · 취약점 대응 실무 · 의존성 CVE 모니터링.
2. 프로덕션 설정과 시크릿 (P0)
- 프로덕션에서는 에러 상세(스택 트레이스)를 외부에 노출하지 마세요 — 내부 구조와 의존성 버전이 새어 나갈 단서를 줄입니다.
- 접속 정보나 키 같은 시크릿은 application.properties/yml에 두지 말고, 환경 변수나 시크릿 매니저(Vault 등)에서 주입하세요. 저장소에 커밋하지 마세요(→ .env 파일과 시크릿).
- 개발용 도구(devtools 등)를 프로덕션에서 활성화하지 마세요.
3. Spring Security 인가 (P1 — 최다 사고원)
흔히 하는(위험)
- 기본값이 느슨해 명시적 허용 설계가 아님
- URL 패턴만으로 지키고, 메서드/소유자 검사가 없음
- 인증은 있지만 "로그인 = 허용"
- 설정 누락으로 일부 엔드포인트가 그대로 통과
올바른
- 기본 거부(명시적으로 허용한 것만 통과)
- 메서드 인가(
@PreAuthorize등) + 소유자 검사 - 조회/수정/삭제의 모든 경로에서 권한/소유자 확인
- 인가를 명시적으로 구성하고, 기본값에 맡기지 않기
용어는 IDOR란 무엇인가. 인증과 인가는 다르며, 인가는 데이터에 가까운 곳에서 합니다.
4. Actuator와 관리 엔드포인트 (P1)
- 노출하는 Actuator 엔드포인트를 최소한(예: health 정도)으로 좁히세요.
- 인증/인가를 필수로 하고, 외부에서 도달할 수 없는 별도 포트/네트워크 경계에 두세요.
env,heapdump,loggers같은 민감한 엔드포인트를 노출하지 마세요(정보 유출 / 조작의 발판이 될 수 있음).
5. 안전하지 않은 역직렬화와 식 평가 (P2)
- 신뢰할 수 없는 데이터를 네이티브 역직렬화하지 마세요(조건에 따라 RCE로 이어질 수 있음). 출처를 검증하고, 필요하면 JSON 같은 안전한 형식으로 한정하세요(→ RCE란 무엇인가).
- 템플릿이나 SpEL이 사용자 입력을 평가하게 두지 마세요. 입력은 Bean Validation 등으로 검증하세요.
6. 인젝션과 데이터 접근 (P2)
- SQL: JPA / JdbcTemplate로 바인딩하고, 문자열 연결로 쿼리를 만들지 마세요(→ SQL 인젝션이란 무엇인가).
- 템플릿에서 HTML을 출력할 때는 출력 인코딩을 거치고, 사용자 입력을 그대로 삽입하지 마세요(XSS 방어).
7. 헤더·HTTPS·세션 (P2)
- Spring Security의 보안 헤더(HTTPS에서 HSTS 등)를 활용하세요. 자기 사이트 상태는 보안 헤더 진단으로 확인하세요.
- HTTPS를 강제하세요. 로드 밸런서 뒤에서는 올바른 스킴/클라이언트 IP를 인식하도록 설정하세요.
- 쿠키에 Secure/HttpOnly/SameSite를 설정하고, CSRF 보호를 유지하며(브라우저 세션에는 기본 활성, API에서 비활성화한다면 대체 보호를 병행), 로그인 시 세션을 재생성하세요.
8. SSRF와 서버 측 외부 요청 (P2)
- 서버가 사용자 지정 URL을 가져오는 처리는 대상을 허용 목록으로 제한하고, 연결 시점에 내부 IP / 클라우드 메타데이터로의 도달을 차단해야 합니다(→ SSRF란 무엇인가).
검증: 당신의 Spring Boot는 정말 단단한가
만들었다고 끝이 아니라, 점검해야 비로소 완료입니다. 아래는 자기 환경에 대한 방어적 자기 점검입니다.
Actuator가 민감한 엔드포인트를 노출하지 않는가
/actuator 아래에 env/heapdump 등이 노출되지 않고 인증이 걸려 있는지 확인.에러가 내부를 흘리지 않는가
인가가 유효한가
의존성과 헤더
본 사이트의 관점: 견고한 토대에서는 의존성과 표면이 승부를 가른다
Spring은 견고한 토대지만, 널리 쓰이기 때문에 바로 의존성 라이브러리의 결함이 모두에게 한꺼번에 파급됩니다. Log4Shell은 그 상징이며, 핵심 방어는 특정 설정이라기보다 의존성을 기계 모니터링하고 가동 중인 버전으로 판단해 빠르게 패치하는 운영 습관입니다. 아울러 편리한 관리 엔드포인트(Actuator)를 공개 표면에서 떼어내고 인가를 기본값에 맡기지 마세요. 본 사이트는 다른 스택이지만 원칙은 똑같습니다 — 의존성의 신선도, 최소 공개 표면, 명시적 인가는 프레임워크를 가리지 않고 통합니다.
다음으로 읽기
- 입구: 프레임워크별 보안 · Next.js 보안
- 사례/실무: Log4Shell 해부 · 취약점 대응 실무 · 의존성 CVE 모니터링
- 용어: IDOR란 무엇인가 · RCE란 무엇인가 · SSRF란 무엇인가
- 도구: 보안 헤더 진단
FAQ
QSpring Boot를 지키려면 먼저 무엇을 해야 하나요?
P0의 세 가지입니다. (1) 의존성 CVE를 기계 모니터링하고 가동 중인 버전으로 판단해 빠르게 패치한다(Log4Shell처럼 토대 라이브러리가 한꺼번에 파급되므로 따라잡는 속도가 관건). (2) 프로덕션에서 상세 에러(스택 트레이스)를 노출하지 않는다. (3) 시크릿(접속 정보·키)을 설정에 하드코딩하지 말고 외부화한다. 그다음 Spring Security 인가와 Actuator 노출 축소로 나아갑니다.
QActuator에서 무엇을 주의해야 하나요?
Actuator는 가동 정보와 진단을 위한 관리 엔드포인트지만, 노출되면 내부 정보가 새거나 설정에 따라 조작의 발판이 될 수 있습니다. 프로덕션에서는 노출을 최소한(예: health 정도)으로 좁히고, 인증과 인가를 필수로 하며, 외부에서 도달할 수 없는 별도 포트/네트워크 경계에 둡니다. env, heapdump, loggers 같은 민감한 엔드포인트는 노출하지 마세요.
QLog4Shell 같은 의존성 결함에 어떻게 대비하나요?
Log4Shell은 널리 상속되는 로깅 라이브러리의 결함이 다수의 앱으로 한꺼번에 파급된 전형적 사례입니다. 대비의 핵심은 의존성 CVE를 기계 모니터링하고 가동 중인 버전으로 판단해 빠르게 패치하는 것입니다(osv-scanner, OWASP dependency-check 등) — pom.xml/gradle의 선언이 아니라 실제로 빌드된 버전으로 판단합니다. 최소 권한과 네트워크 분리도 폭발 반경을 줄여줍니다.
QSpring Security 인가는 어떻게 써야 안전한가요?
기본을 거부 쪽으로 기울이고(명시적으로 허용한 것만 통과), URL 패턴에만 의존하지 말며, 적절한 곳에서 메서드 수준 인가(@PreAuthorize 등)를 사용하세요. 로그인(인증) 위에, 대상 리소스가 정말 그 사용자의 것인지 확인하는 소유자 검사를 구현합니다. 설정 누락이 권한 상승의 구멍이 되므로 인가는 명시적으로 구성합니다.
Q안전하지 않은 역직렬화는 왜 위험한가요?
신뢰할 수 없는 데이터를 Java 네이티브 역직렬화로 복원하면 조건에 따라 원격 코드 실행(RCE)으로 이어질 수 있습니다. 외부 유래 데이터를 그대로 복원하지 말고, 출처를 검증하며, 필요하면 JSON 같은 안전한 형식으로 한정하세요. 마찬가지로 템플릿이나 식 언어(SpEL)가 사용자 입력을 평가하도록 두지 마세요.