dependency management
이 태그가 달린 문서 4건
Express(Node.js) 보안 대책 — 방어는 '직접 더한다'
Express는 최소주의 = 기본값으로 보안 기능을 거의 갖지 않습니다. 그래서 방어는 개발자가 '직접 더하는' 것. 핵심 = (1) 보안 헤더(helmet 상당) (2) 입력 검증과 새니타이즈 (3) 인증뿐 아니라 소유자 스코프 인가 (4) 레이트 리밋(무차별 대입·DoS 대책) (5) 의존성 패키지(npm)의 CVE 모니터링 + 즉시 패치. 더해 외부 URL 취득은 SSRF 대책, 시크릿은 환경 변수에 두고 코드에 섞지 않기. 최소한의 자유와 맞바꾸어, 방어의 책임도 자신에게 있습니다.
Next.js 보안 대책 — Server Actions·환경 변수·의존성 CVE의 방어법
Next.js는 기본값이 안전한 편이지만, 사고는 '서버와 클라이언트의 경계'에서 일어난다. 3대 = (1) 환경 변수의 노출(NEXT_PUBLIC_의 오용이나 서버 전용 시크릿을 클라이언트로 넘김) (2) Server Actions / Route Handlers의 인가 누락(인증은 있지만 소유자 스코프가 없음) (3) 의존성 패키지의 알려진 CVE(프레임워크 본체의 RCE 포함·가동 중인 버전으로 판단하고 즉시 패치). 방어 = 시크릿은 서버 한정·경계를 의식·Server Actions에서 인가를 매번 확인·의존성 CVE를 기계 모니터링.
Ruby on Rails 보안 대책 — Strong Parameters·인가·gem CVE 방어법
Rails는 규약과 안전한 기본값(CSRF 보호·Strong Parameters·ORM)을 갖추어 올바르게 쓰면 견고합니다. 하지만 사고는 운영에서 일어납니다. 3대 = (1) Strong Parameters를 과다 허용해 Mass Assignment(is_admin 등의 예상 밖 덮어쓰기) (2) 인가의 작업 부족(로그인=인증은 있지만 소유자 스코프가 없음) (3) gem(의존성)의 알려진 CVE. 더해 where로의 문자열 결합에 의한 SQLi, send/constantize 등의 위험한 동적 메서드, credentials/secret_key_base의 누출. 방어 = permit를 좁히기·인가를 명시·gem을 CVE 모니터링.
Spring Boot 보안 대책 — 의존성 CVE·Actuator 노출·인가의 방어법
Spring(Spring Boot)은 엔터프라이즈 정석. 사고의 유형 = (1) 의존성 라이브러리의 알려진 CVE(Log4Shell처럼 널리 상속되는 토대의 구멍·가동 중인 버전으로 판단하고 즉시 패치) (2) Actuator 등 관리/진단 엔드포인트의 노출(정보 유출·조작) (3) Spring Security의 인가 설정 누락(인증은 있지만 권한 검사가 느슨) (4) 안전하지 않은 역직렬화. 방어 = 의존성 CVE를 기계 모니터링해 즉시 패치·Actuator/관리 표면 좁히기·인가를 명시·신뢰할 수 없는 데이터를 역직렬화하지 않기.