[FE 개념정리] 상태 및 보안, DOM

정은·2025년 6월 13일

HTTP 상태 401과 403의 차이

  • 401 (Unauthorized): 인증이 필요하거나, 인증이 실패한 경우
  • 403 (Forbidden): 인증은 되었지만 해당 리소스 권한 없음

쿠키와 세션 보안 측면

  • 쿠키보다 세션이 안전
    • 인증 정보는 서버에만 저장됨
    • 클라이언트는 세션 ID만 전달
    • 서버에서 강제 로그아웃, 만료 처리 통제 가능
  • JWT 사용 시 HTTP 헤더에 담아 전송
    • 서버는 토큰의 유효성과 서명만 검증
  • JWT 사용 전략
1. Access Token 헤더 전송
2. Access Token 만료 시 Refresh Token 발급
3. refresh 요청 시 이전 토큰 폐기 및 새로운 refresh token 발급

* Refresh Token은 `HttpOnly + Secure + SameSite=Strict` 쿠키에 저장

React에서의 DOM 컨트롤 방법

1️⃣ useRef() + .current: 특정 DOM 요소에 직접 접근 시 사용

import { useRef, useEffect } from 'react';

function MyComponent() {
  const inputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    if (inputRef.current) {
      inputRef.current.focus();
    }
  }, []);

  return <input ref={inputRef} />;
}

2️⃣ useEffect(): DOM이 렌더링 된 후 동작을 수행할 때 사용

useEffect(() => {
  console.log(document.getElementById('myDiv')?.innerText);
}, []);

3️⃣ className/style props: DOM 속성을 선언적으로 제어

<div className={isActive ? 'active' : ''} style={{ color: 'red' }}>
  Hello
</div>

4️⃣ dangerouslySetInnerHTML: HTML 문자열을 DOM 삽입 시 사용 (XSS 위험)

<div dangerouslySetInnerHTML={{ __html: '<b>Hello</b>' }} />

✏️ 직접 접근이 필요한 경우에만 ref로 제한적으로 사용하는 것이 베스트


XSS와 CSRF

XSS: 악성 스크립트를 웹사이트에 삽입해서 다른 사용자의 브라우저에서 실행되게 하는 공격

  • 공격 대상: 사용자
  • <input>, <textarea>, 댓글, 게시판 등 사용자가 입력을 표시하는 곳에서 발생
  • 쿠키 탈취 및 세션 하이재킹, 사용자 입력 조작 등의 목적

CSRF: 사용자가 로그인된 상태에서, 공격자가 만든 요청을 사용자 의지와 무관하게 실행되게 하는 공격

  • 공격대상: 서버
  • 예시: <img src="http://bank.com/transfer?amount=10000&to=hacker">
  • 로그인된 사용자의 권한으로 요청. 무단 송금, 비밀번호 변경 등 서버 상태 변경

🔒 해결방법

XSS : 출력 시 반드시 이스케이프 처리 및 입력값 필터링, 
	  CSP(악성 스크립트 차단) 적용, 쿠키에 HttpOnly 속성 설정
     
CSRF : CSRF 토큰 사용 및 SameSite 쿠키 옵션 설정, 
	   origin 헤더 검증, 로그아웃 시 세션 무효화, 세션 timeout 설정


그리고.. 실제 서비스에서의 Next.js의 단점/제약 정리 (App Router 기준)

😬 서버 컴포넌트 + 클라이언트 컴포넌트 분리의 복잡성

  • 컴포넌트 내부에서 useState, useEffect, event listener 사용 시 use client 필요
  • 이로 인해 모든 버튼 컴포넌트마다 use client를 붙이게 되거나, SSR 의도가 무너질때도 있다.. (경험담 ... ^^)

🐝 App Router 구조와 Page Router 구조의 충돌

  • 기존 page router 기반 프로젝트에서 app router로 마이그레이션 시 혼합 사용 불가
  • 구조/라이프사이클/라우팅 방식이 완전히 다름
    ex) getServerSidePropsserver component or fetch로 대체
  • 그렇기 때문에 일부만 마이그레이션 불가. 기존 라이브러리와 호환 이슈 발생

👾 레이아웃 구조 복잡화

  • 페이지마다 layout.tsx, loading.tsx, error.tsx 등 여러 파일 관리 필요
  • 유지보수 시 새로 들어온 팀원이 구조파악 힘들때가 있다.. 🥲

❄️ 미들웨어 제약

  • 리디렉션, 쿠키 읽기, 헤더 검사, JWT 토큰 단순검사 등 가벼운 조건 체크는 적합!
  • 하지만 고급 인증/인가 처리는 API Route 또는 서버에서 따로 처리를 해야하는 이슈가 있다

Next의 장점은 충분히 알고 있지만, 단점에 대한 질문이 나오면 바로 답변이 나오지 않아서 정리해봤다 ㅎㅎ..

0개의 댓글