프레임워크별 보안

WordPress는 최대 점유율 = 통계적으로 가장 큰 표적입니다. 사고의 입구는 본체의 버그보다 '플러그인/테마 취약점·방치된 업데이트·약한/재사용 관리자·노출된 관리 화면(wp-admin/xmlrpc/REST 열거)'입니다. 방어 = 본체와 플러그인 업데이트 자동화·안 쓰는 플러그인/테마 삭제·관리자에 강한 비밀번호+2FA·관리 화면 노출과 로그인 시도 제한·변조 탐지와 오프라인 백업.

Laravel은 기본값이 비교적 안전한 반면, 사고의 대부분은 운영 측면에서 일어납니다. 3대 함정 = (1) .env나 시크릿 파일이 공개 디렉터리(public)에서 URL로 가져와짐, (2) 운영 환경에서 APP_DEBUG=true인 채 = 에러 화면에 환경 변수·접속 정보가 노출, (3) 인가 누락(로그인=인증은 있지만 소유자 스코프 인가가 없음 / Mass Assignment로 의도치 않은 필드 덮어쓰기). 방어 = 시크릿을 public 밖 + 권한 600·운영 환경은 debug off + 설정 캐시·Policy/Gate로 인가·$fillable 명시.

Next.js는 기본값이 안전한 편이지만, 사고는 '서버와 클라이언트의 경계'에서 일어난다. 3대 = (1) 환경 변수의 노출(NEXT_PUBLIC_의 오용이나 서버 전용 시크릿을 클라이언트로 넘김) (2) Server Actions / Route Handlers의 인가 누락(인증은 있지만 소유자 스코프가 없음) (3) 의존성 패키지의 알려진 CVE(프레임워크 본체의 RCE 포함·가동 중인 버전으로 판단하고 즉시 패치). 방어 = 시크릿은 서버 한정·경계를 의식·Server Actions에서 인가를 매번 확인·의존성 CVE를 기계 모니터링.

Express는 최소주의 = 기본값으로 보안 기능을 거의 갖지 않습니다. 그래서 방어는 개발자가 '직접 더하는' 것. 핵심 = (1) 보안 헤더(helmet 상당) (2) 입력 검증과 새니타이즈 (3) 인증뿐 아니라 소유자 스코프 인가 (4) 레이트 리밋(무차별 대입·DoS 대책) (5) 의존성 패키지(npm)의 CVE 모니터링 + 즉시 패치. 더해 외부 URL 취득은 SSRF 대책, 시크릿은 환경 변수에 두고 코드에 섞지 않기. 최소한의 자유와 맞바꾸어, 방어의 책임도 자신에게 있습니다.

Spring(Spring Boot)은 엔터프라이즈 정석. 사고의 유형 = (1) 의존성 라이브러리의 알려진 CVE(Log4Shell처럼 널리 상속되는 토대의 구멍·가동 중인 버전으로 판단하고 즉시 패치) (2) Actuator 등 관리/진단 엔드포인트의 노출(정보 유출·조작) (3) Spring Security의 인가 설정 누락(인증은 있지만 권한 검사가 느슨) (4) 안전하지 않은 역직렬화. 방어 = 의존성 CVE를 기계 모니터링해 즉시 패치·Actuator/관리 표면 좁히기·인가를 명시·신뢰할 수 없는 데이터를 역직렬화하지 않기.

Django는 '배터리 포함'으로 안전한 기본값(ORM·CSRF·템플릿 자동 이스케이프·인증)을 갖추어 올바르게 설정하면 견고합니다. 하지만 사고는 설정에서 일어납니다. 3대 = (1) 운영 환경에서 DEBUG=True = 오류 화면에 설정·환경 변수·시크릿이 노출 (2) SECRET_KEY의 누출(서명·세션의 토대) (3) 인가의 작업 부족(is_staff/권한 확인 누락). 더해 raw()/extra()나 문자열 결합에 의한 SQLi, pickle 등의 안전하지 않은 역직렬화, ALLOWED_HOSTS 미설정, 의존성(pip)의 CVE. 방어 = 운영 DEBUG=False·SECRET_KEY는 환경에서·인가를 명시.

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 모니터링.

ASP.NET Core는 성숙한 견고한 기반이지만, 사고는 설정에서 일어납니다. 3대 = (1) 운영 환경에서 상세 오류/개발자 예외 페이지를 노출(내부 정보 누출) (2) appsettings.json에 시크릿 직접 기재(User Secrets/환경 변수/Key Vault를 사용) (3) 인가 속성([Authorize])의 부착 누락. 더해 BinaryFormatter 등의 안전하지 않은 역직렬화, 모델 바인딩의 과잉 수용(over-posting = DTO/[Bind]로 제한), NuGet 의존성의 CVE. 방어 = 운영은 상세 오류 비표시·시크릿은 설정 외부에서·인가를 명시.