framework
이 태그가 달린 문서 9건
Django 보안 — 프로덕션 하드닝 실무 레퍼런스
Django는 '배터리 포함'의 안전한 기본값(ORM·CSRF·자동 이스케이프·인증)을 갖추지만, 사고는 설정에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — DEBUG=False＋ALLOWED_HOSTS·SECRET_KEY의 외부화·pip 의존성 CVE·프로덕션 보안 설정(SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE 등)·인가(소유자 스코프)·인젝션과 출력(raw/extra·mark_safe)·CSRF/세션/admin·SSRF/업로드, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
프레임워크별 보안 대책 — 사용하는 기술에 맞는 방어법
프레임워크가 달라져도 공격자가 노리는 약점의 '유형'(접근 제어·시크릿 관리·인젝션·의존성 CVE·설정 오류)은 거의 공통입니다. 다른 것은 '위험한 기본 설정'과 '그 기술에서 자주 노려지는 지점'뿐. 본 사이트는 각 프레임워크의 '기본값의 함정'과 '하드닝 절차'를 하나씩 준비합니다. 우선 자신이 실제로 쓰는 프레임워크 장부터.
Laravel 보안 — 프로덕션 하드닝 레퍼런스
Laravel의 기본값은 견고합니다. 프로덕션 사고는 설정과 운영에서 나옵니다. 이 문서는 실무용 레퍼런스입니다: (1) 우선순위순 하드닝 체크리스트(P0–P2), (2) 위험한 기본값 표, (3) 영역별 지침 — 시크릿/APP_KEY, 프로덕션 설정(APP_DEBUG/캐시), 인가(Policy/Gate, Mass Assignment), 인젝션/출력(Eloquent 바인딩, Blade), 세션/CSRF/쿠키, 업로드, HTTPS/헤더/속도 제한, Composer 의존성 CVE, 그리고 (4) 자기 점검 체크리스트. 방어 전용이며 공격 절차는 없습니다.
Next.js 보안 대책 — 프로덕션 하드닝 실무 레퍼런스
Next.js의 기본값은 비교적 안전하지만, 사고는 서버/클라이언트 경계에서 일어납니다. 이 페이지는 실무 레퍼런스입니다: (1) 우선순위별 하드닝 체크리스트(P0–P2), (2) 영역별 지침 — 경계와 환경 변수(NEXT_PUBLIC_), 의존성 CVE(본체 RCE 포함), Server Actions / Route Handlers 인가 + 입력 검증, 서버 측 fetch의 SSRF, 보안 헤더/CSP, 인증/세션/쿠키, 레이트 제한, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차 없음.
Spring Boot 보안 — 프로덕션 하드닝 실무 레퍼런스
Spring Boot는 견고한 토대지만, 사고는 의존성·설정·인가에서 일어난다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 의존성 CVE(Log4Shell급, 가동 중인 버전으로 판단)·프로덕션 설정과 시크릿 외부화·Spring Security 인가(기본 거부/메서드 인가/소유자 검사)·Actuator/관리 노출 축소·안전하지 않은 역직렬화·인젝션·헤더/CSRF/세션·SSRF, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.
WordPress 보안 대책 — 프로덕션 하드닝 실무 레퍼런스
WordPress는 점유율이 가장 크므로 가장 큰 표적이지만, 입구는 예측 가능합니다(플러그인/테마 취약점, 방치된 업데이트, 약한 관리자, 노출된 관리 화면). 이 페이지는 실무 레퍼런스입니다: (1) 우선순위별 하드닝 체크리스트(P0–P2), (2) 영역별 지침 — 자동 업데이트, 플러그인/테마 최소화, 강한 관리자 + 2FA, 관리 화면 노출 축소(xmlrpc/REST 열거/파일 편집), wp-config와 시크릿, 파일 권한, HTTPS/백업, PHP/의존성 신선도, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차 없음.
ASP.NET Core 보안 — 프로덕션 하드닝 실무 레퍼런스
ASP.NET Core는 성숙하고 견고한 기반이지만, 사고는 설정에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — 프로덕션에서 상세 오류/Developer Exception Page를 노출하지 않기·시크릿의 외부화(User Secrets/환경/Key Vault)·NuGet 의존성 CVE·인가([Authorize]·폴백으로 기본 거부·리소스 기반/소유자)·over-posting(DTO/[Bind])·안전하지 않은 역직렬화(BinaryFormatter 회피)·HTTPS/헤더/antiforgery·SSRF, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
Express(Node.js) 보안 — 프로덕션 하드닝 실무 레퍼런스
Express는 최소주의라 기본으로 거의 아무것도 지키지 않으므로 방어는 직접 더한다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 보안 헤더(helmet) + x-powered-by 비활성화·npm 의존성 CVE·입력 검증과 인젝션(SQL/NoSQL 연산자)·인증과 소유자 스코프 인가·속도 제한과 크기 상한·세션/쿠키/CSRF·SSRF·프로덕션 에러 처리(스택 미노출)·NODE_ENV, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.
Ruby on Rails 보안 — 프로덕션 하드닝 실무 레퍼런스
Rails는 규약과 안전한 기본값(CSRF 보호·Strong Parameters·ORM)을 갖추지만, 프로덕션 사고는 운영에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — 비밀과 credentials(master key/secret_key_base)·프로덕션 설정(force_ssl·예외 비노출)·gem CVE·Strong Parameters/Mass Assignment·인가(Pundit 등·소유자 스코프)·인젝션과 위험한 메서드(where 결합/send/constantize)·세션/Cookie/CSRF·SSRF/업로드, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.