프레임워크별
Express(Node.js) 보안 — 프로덕션 하드닝 실무 레퍼런스
Express(Node.js)를 안전하게 운영하기 위한 프로덕션 하드닝 레퍼런스. 최소주의라 방어는 직접 더한다 — helmet 헤더·npm CVE·입력 검증·인가·속도 제한·세션/CSRF·SSRF까지. 방어 중심, 공격 절차는 다루지 않습니다.
대상: Express(Node.js)로 API나 앱을 운영하는 사람. 여기서는 공격 절차를 다루지 않고, 최소 프레임워크에 더하는 방어를, 프로덕션을 위한 실무 레퍼런스(우선순위 체크리스트·영역별 대책·자기 검증)로 제시합니다. 프레임워크 전반의 그림은 프레임워크별 보안 입구도 참고하세요.
우선순위 순 하드닝 체크리스트
이 표를 위에서부터 실행하세요. P0는 전제, P1은 가장 잦은 사고원, P2는 지속적인 운영 위생입니다.
P0 ── 전제(먼저 이것)
헤더(helmet) + x-powered-by 비활성화 / npm 의존성 CVE 모니터링 / 시크릿을 env에서·스택 미노출
P1 ── 최다 사고원
입력 검증과 인젝션 방어 / 소유자 스코프 인가
P2 ── 운영 위생
속도 제한과 크기 상한 / 세션·쿠키·CSRF / SSRF
| 우선순위 | 대책 | 구체(Express) |
|---|---|---|
| P0 | 보안 헤더 | helmet류: CSP/HSTS/X-Content-Type 등. x-powered-by 비활성화 |
| P0 | npm 의존성 CVE | npm audit/osv-scanner로 감시; 가동 중인 버전으로 판단하고 빠르게 패치 |
| P0 | 시크릿과 에러 | 시크릿은 env 변수에서. 프로덕션에서 스택 트레이스를 노출하지 않기 |
| P1 | 입력 검증 | 입력을 검증/새니타이즈(형·범위·허용값). 바디 크기 상한 |
| P1 | 인젝션 | DB 쿼리를 바인딩. NoSQL 연산자 인젝션($) 주의. eval에 입력을 넘기지 않기 |
| P1 | 인가 | 인증 + 각 라우트에서 소유자 스코프 인가. JWT: 서명 검증, alg 고정 |
| P2 | 속도 제한 | 로그인/API에 시도/처리량 제한. 무차별 대입·남용·DoS 억제 |
| P2 | 세션/쿠키 | secure/httpOnly/sameSite. CSRF(쿠키 세션). 프로덕션용 세션 스토어 |
| P2 | SSRF | 서버 측 외부 요청은 허용 목록으로 제한 + 내부 IP/메타데이터 차단 |
1. 보안 헤더와 노출 축소 (P0)
Express는 기본으로 보안 헤더를 설정하지 않습니다. 먼저 이 기본선을 끌어올리세요.
- helmet류 미들웨어로 CSP, HSTS, X-Content-Type-Options, frameguard 등을 붙이세요.
x-powered-by를 비활성화해 프레임워크/버전 노출을 줄이세요.- 자기 사이트 상태는 보안 헤더 진단으로 확인하세요.
2. 의존성(npm)과 공급망 (P0)
- 의존성 CVE를
npm audit이나 osv-scanner로 기계 모니터링하고, 가동 중인 버전으로 판단해 빠르게 패치하세요(→ 의존성 CVE 모니터링). - Node는 의존성 트리가 크고 공급망 위험(typosquatting,
postinstall훅)이 있습니다. 설치 시점에 검토하고 개수를 줄이세요. - **Node를 지원 버전(LTS)**으로 유지하고 EOL 버전을 방치하지 마세요.
3. 입력 검증과 인젝션 (P1)
- 모든 입력(바디, 쿼리, 파라미터, 헤더)을 검증/새니타이즈하세요. DoS를 억제하려면 바디 크기 상한을 두세요.
- SQL: 플레이스홀더로 바인딩하고, 문자열 연결로 쿼리를 만들지 마세요(→ SQL 인젝션이란 무엇인가).
- NoSQL: 객체 타입 입력을 통한 **연산자 인젝션(
$)**에 주의하세요(생 객체를 쿼리에 넘기지 않기). eval같은 위험한 평가에 외부 입력을 넘기지 마세요.
4. 인증과 인가 (P1)
흔히 하는(위험)
- 인가가 없어 "로그인 = 허용"
- 미들웨어의 순서/존재에만 의존
- 클라이언트가 준 ID/플래그를 그대로 신뢰
- JWT 서명 미검증 /
alg:none허용
올바른
- 인증에 더해 각 라우트에서 소유자 스코프 인가
- 데이터에 가까운 곳에서 확인(순서에 의존하지 않기)
- 서버에서 재검증(ID 바꿔치기에 견딤)
- JWT 서명 검증 + alg 고정(
alg:none거부)
용어는 IDOR란 무엇인가 · JWT란 무엇인가. JWT의 내용은 직접 검사할 수 있습니다(JWT 디코더).
5. 속도 제한과 남용 대책 (P2)
- 로그인, API, 비밀번호 재설정에 시도/처리량 제한을 걸어 무차별 대입, 남용, DoS를 억제하세요.
- 요청 바디와 업로드에 크기 상한을 두세요(큰 페이로드에 의한 고갈 방지).
6. 세션과 쿠키 (P2)
- 세션 쿠키에 **
secure/httpOnly/sameSite**를 설정하세요. - 쿠키 세션 앱은 CSRF 보호를 넣으세요(→ CSRF란 무엇인가).
- 프로덕션에서는 적절한 세션 스토어를 쓰세요(기본 인메모리 스토어는 프로덕션용이 아님). 로그인 시 세션을 재생성하세요.
7. SSRF와 서버 측 외부 요청 (P2)
- 서버가 사용자 지정 URL을 가져오는 처리는 대상을 허용 목록으로 제한하고, 연결 시점에 내부 IP / 클라우드 메타데이터로의 도달을 차단해야 합니다(→ SSRF란 무엇인가).
8. 에러 처리와 프로덕션 설정 (P0~P2)
- 중앙 에러 핸들러를 사용하고, 스택 트레이스를 외부에 노출하지 마세요.
- **
NODE_ENV=production**으로 실행하세요. 프록시 뒤에서는 **trust proxy**를 올바르게 설정해 스킴과 클라이언트 IP를 오인하지 않도록 하세요. - TLS/HTTPS를 확실히 종단하세요.
검증: 당신의 Express는 정말 단단한가
만들었다고 끝이 아니라, 점검해야 비로소 완료입니다. 아래는 자기 환경에 대한 방어적 자기 점검입니다.
헤더와 노출
x-powered-by가 사라졌는지를 헤더 진단으로 확인.에러가 내부를 흘리지 않는가
인가가 유효한가
의존성·속도 제한·SSRF
npm audit/osv가 클린한지, 로그인 속도 제한이 작동하는지, 외부 요청이 내부 IP에 도달하지 못하는지 확인.본 사이트의 관점: 최소 프레임워크는 자유와 책임이 한 세트
Express의 매력은 가벼움과 자유입니다 — 그것은 곧 방어도 직접 설계한다는 뜻입니다. Rails와 Laravel이 기본으로 지키는 부분(헤더, CSRF, 인가 골격)을 Express에서는 의식적으로 짜 넣습니다. 무게 중심은 위 표를 위에서부터 처리하는 것 — 헤더를 붙이고, 입력을 검증하고, 공개 진입점에 인가를 작성하고, 의존성을 CVE 모니터링하는 것입니다. 특히 Node는 의존성 개수가 많아 의존성의 신선도가 사고를 가릅니다. "프레임워크가 지켜주겠지"라는 전제를 버리고 방어를 명시적으로 더하세요.
다음으로 읽기
- 입구: 프레임워크별 보안 · Next.js 보안(같은 Node 계열)
- 실무: 의존성 CVE 모니터링 · 취약점 대응 실무
- 용어: IDOR란 무엇인가 · SSRF란 무엇인가 · JWT란 무엇인가 · CSRF란 무엇인가
- 도구: 보안 헤더 진단 · JWT 디코더
FAQ
QExpress를 지키려면 먼저 무엇을 해야 하나요?
P0의 세 가지입니다. (1) helmet류 미들웨어로 보안 헤더(CSP/HSTS 등)를 붙이고 x-powered-by를 비활성화한다. (2) npm 의존성 CVE를 기계 모니터링하고 가동 중인 버전으로 판단해 빠르게 패치한다. (3) 시크릿을 환경 변수에서 읽고, 프로덕션에서 스택 트레이스를 노출하지 않는다. Express는 기본으로 이것들을 지켜주지 않으므로 직접 더하는 것이 기본선입니다. 그다음 입력 검증·인가·속도 제한으로 나아갑니다.
Qhelmet 같은 보안 헤더가 필요한가요?
네. Express는 기본으로 보안 관련 HTTP 헤더를 설정하지 않습니다. helmet류 미들웨어로 CSP, HSTS, X-Content-Type-Options 등을 붙여 클릭재킹이나 MIME 스니핑 같은 기초적 위험을 낮추세요. 아울러 x-powered-by를 비활성화해 프레임워크 노출을 줄입니다. 붙이는 것만으로 기본선이 올라가므로 가장 먼저 넣으세요.
Q인증과 인가는 어떻게 구성하나요?
인증 미들웨어로 로그인을 확인한 뒤, 각 라우트에 소유자 스코프 인가 — 대상이 정말 그 사용자의 것인지 — 를 반드시 작성하세요. 미들웨어의 순서나 단순 존재에 의존하지 말고, 데이터에 가까운 곳에서 확인합니다. JWT를 쓴다면 서명 검증을 필수로 하고 alg를 고정하세요(alg:none 거부).
Qnpm 의존성 취약점은 어떻게 관리하나요?
npm audit이나 osv-scanner로 알려진 CVE를 기계 모니터링하고, 가동 중인 버전으로 판단해 빠르게 패치하세요. Node는 의존성 트리가 매우 크고 공급망 위험(typosquatting, postinstall 훅)이 있어, 의존성의 신선도와 설치 시점의 검토가 승부를 가릅니다. Node도 지원 버전(LTS)으로 유지하세요.
Q최소한으로 무엇을 해야 하나요?
(1) helmet류 헤더 + x-powered-by 비활성화, (2) 모든 입력을 검증/새니타이즈, (3) 소유자 스코프 인가, (4) 로그인/API에 속도 제한 + 바디 크기 상한, (5) npm 의존성 CVE 모니터링 + 빠른 패치, (6) 프로덕션에서 스택 트레이스 미노출. 이 최소 세트로 최소 프레임워크의 빈틈을 대부분 메웁니다.