서버 컴포넌트라서 안전하다? 착각이다
Next.js 13 이후 서버 컴포넌트(RSC)가 기본이 됐다. AI 코딩 도구에게 "Next.js로 대시보드 만들어줘"라고 하면 서버 컴포넌트를 적극 활용한다. 문제는 "서버에서 실행되니까 안전하겠지"라는 착각이다.
실제로 CodeScan에서 Next.js 프로젝트 30개를 점검한 결과, 서버 컴포넌트를 사용하는 프로젝트의 73%에서 보안 취약점이 발견됐다.
실수 1: 환경변수가 클라이언트에 노출
서버 컴포넌트에서 환경변수를 사용하면 서버에서만 접근된다. 하지만 AI가 생성한 코드에서 이런 패턴이 자주 나타난다:
// 서버 컴포넌트에서 API 키를 props로 내려보냄
export default async function Dashboard() {
const apiKey = process.env.STRIPE_SECRET_KEY;
return <PaymentForm apiKey={apiKey} />; // 클라이언트로 전달!
}서버 컴포넌트 자체는 서버에서 실행되지만, props로 넘긴 데이터는 클라이언트 번들에 포함된다. 결제 API 키, DB 접속 정보가 브라우저 소스에 그대로 노출된다.
수정법: 서버 컴포넌트에서 API 호출을 완료하고, 결과만 클라이언트에 전달한다. 민감한 값은 절대 props로 내리지 않는다.
실수 2: 서버 액션에서 권한 체크 누락
Next.js Server Actions는 편리하지만, AI가 생성한 코드에서 권한 검증이 빠지는 경우가 많다:
'use server'
export async function deleteUser(userId: string) {
// 권한 체크 없이 바로 삭제
await db.user.delete({ where: { id: userId } });
}Server Action은 POST 엔드포인트로 노출된다. 누구나 userId만 알면 다른 사용자를 삭제할 수 있다. 실무에서 가장 많이 발견되는 취약점이다.
수정법: 모든 Server Action 첫 줄에 세션 확인 + 권한 체크를 넣는다. 미들웨어로 일괄 적용하는 것도 방법이다.
실수 3: 동적 라우트에서 다른 사용자 데이터 접근
AI가 만든 마이페이지, 주문 상세 같은 페이지에서 흔히 발생한다:
// app/orders/[id]/page.tsx
export default async function OrderPage({ params }) {
const order = await db.order.findUnique({ where: { id: params.id } });
// 이 주문이 현재 로그인한 사용자 것인지 확인하지 않음
return <OrderDetail order={order} />;
}URL의 ID만 바꾸면 다른 사용자의 주문 내역, 결제 정보, 개인정보를 볼 수 있다. IDOR(Insecure Direct Object Reference) 취약점이다.
수정법: 데이터 조회 시 반드시 현재 사용자 ID 조건을 추가한다: where: { id: params.id, userId: session.userId }
실수 4: API 라우트 인증 미들웨어 미적용
Next.js의 app/api/ 라우트에 인증 미들웨어를 적용하지 않는 경우가 많다. AI는 기능 구현에 집중하기 때문에 middleware.ts의 matcher 설정에서 API 라우트를 빠뜨린다.
결과적으로 로그인하지 않은 사용자가 관리자 API, 결제 API, 데이터 삭제 API에 직접 접근할 수 있다.
수정법: middleware.ts에서 /api/ 경로를 matcher에 포함시키고, 공개 API만 예외 처리한다.
30초 만에 확인하는 방법
직접 코드를 한 줄씩 검토할 시간이 없다면, 자동 스캐너로 먼저 확인하자. URL만 입력하면 환경변수 노출, API 인증 누락, 보안 헤더 설정까지 한 번에 점검할 수 있다.