프레임워크별
Express(Node.js) 보안 대책 — 방어는 '직접 더한다'
Express는 최소주의 프레임워크라 기본값으로는 거의 아무것도 지켜주지 않습니다. 그래서 방어는 '직접 더하는' 것 — 보안 헤더·입력 검증·인가(인증에서 멈추지 않기)·레이트 리밋·의존성(npm) CVE 모니터링. 무엇을 어떻게 더하는지, 공격 절차는 빼고 방어 관점으로 풀어냅니다.
대상: Express(Node.js)로 API나 앱을 운영하는 사람. 여기서는 공격 절차를 다루지 않고, 최소 프레임워크에 '직접 더하는' 방어를 풀어냅니다. 전체 그림은 프레임워크별 보안의 입구도 참조하세요.
'직접 더하는' 방어(기본값에 없는 영역)
Express는 라우팅과 미들웨어의 토대만 제공합니다. 다음 방어는 당신이 더하지 않으면 존재하지 않습니다.
보안 헤더
CSP/HSTS/X-Content-Type 등. helmet 상당으로 부여.
입력 검증
검증되지 않은 입력이 SQLi/XSS/인젝션의 입구가 된다.
인가(소유자 스코프)
인증에서 멈추면 ID 교체로 남의 데이터(IDOR).
레이트 리밋
로그인 무차별 대입·API 남용·DoS를 억제.
의존성(npm)의 CVE
대량의 의존성의 알려진 취약점을 기계 모니터링 + 즉시 패치.
시크릿과 SSRF
시크릿은 환경 변수·코드에 섞지 않기 / 외부 URL 취득은 SSRF 대책.
막는 법(최소한의 5가지)
보안 헤더를 붙인다
모든 입력을 검증·새니타이즈
인증에서 멈추지 말고 인가를 작성
레이트 리밋과 의존성 CVE 모니터링
자주 하는(위험한)
- 헤더를 붙이지 않은 맨 응답
- 입력을 검증하지 않고 DB나 HTML로
- 인가를 작성하지 않고 "로그인 = 허가"
- 레이트 리밋 없음·의존성 CVE 방치
올바른
- helmet 상당으로 헤더 부여
- 입력을 검증·새니타이즈
- 소유자 스코프 인가
- 레이트 리밋 + 의존성 CVE 모니터링 + 즉시 패치
본 사이트의 관점: 최소 프레임워크는 '자유와 책임'이 세트
Express의 장점은 가벼움과 자유도이지만, 그것은 방어도 직접 설계한다는 뜻입니다. 본 사이트는 다른 스택이지만, Node 계열에서 지킬 요점은 같습니다 — 헤더를 붙이고, 입력을 검증하고, 공개 입구에는 반드시 인가를 작성하고, 의존성은 매 배포 전에 CVE를 감사한다. 특히 Node는 의존성 개수가 많아 의존성의 신선도가 사고를 가릅니다. "프레임워크가 지켜주겠지"라는 전제를 버리고, 방어를 명시적으로 더하는 것이 Express의 올바른 사용법입니다.
다음으로 읽기
- 입구: 프레임워크별 보안(입구) / Next.js 보안 대책(같은 Node 계열)
- 실무: 의존성 CVE 모니터링 / 도구: 보안 헤더 진단
- 용어: IDOR란 / SSRF란
FAQ
QExpress는 안전한 프레임워크인가요?
Express는 '최소주의' 설계로, 라우팅과 미들웨어의 토대만 제공하고 보안 기능은 거의 내장하지 않습니다. 즉 안전하지도 위험하지도 않으며, 방어는 개발자가 직접 더하는 것을 전제로 합니다. 많은 것을 기본값으로 지켜주는 Rails나 Laravel과 달리, 헤더·입력 검증·인가·레이트 리밋 등을 직접 조합해 넣어야 합니다. 자유도가 높은 만큼 책임도 자신에게 있습니다.
Qhelmet 같은 보안 헤더가 필요한가요?
네. Express는 기본값으로 보안 관련 HTTP 헤더를 붙이지 않습니다. helmet 상당의 미들웨어로 CSP·HSTS·X-Content-Type-Options 등을 부여해, 클릭재킹이나 MIME 스니핑 같은 초보적 위험을 낮추는 것이 기본입니다. 붙이는 것만으로도 수준이 올라가므로, 가장 먼저 넣어둘 가치가 있습니다.
Q최소한 무엇을 해야 하나요?
(1) 보안 헤더(helmet 상당)를 붙이고, (2) 모든 입력을 검증·새니타이즈하고, (3) 로그인(인증)에서 멈추지 말고 소유자 스코프 인가를 작성하고, (4) 로그인과 API에 레이트 리밋을 걸고, (5) 의존성 패키지(npm)의 CVE를 기계적으로 모니터링해 즉시 패치합니다. 이 다섯 가지로 최소 프레임워크의 구멍 대부분을 메울 수 있습니다.