Vercel/Netlify 배포 사이트 보안 점검 가이드 (2026)

JAMstack 배포 플랫폼과 보안의 역설

Vercel과 Netlify는 개발자 경험이 뛰어납니다. git push 하나로 전 세계 CDN에 배포되고, SSL 인증서는 자동으로 발급됩니다. 그러나 편의성이 높을수록 보안 실수도 쉽게 일어납니다. 프레임워크 동작 방식을 정확히 이해하지 못하면 민감한 정보가 클라이언트 번들에 포함되거나, 빌드 로그에 시크릿이 노출됩니다.

이 가이드는 2026년 기준으로 Vercel·Netlify 배포 사이트에서 자주 발견되는 보안 취약점 5가지를 점검 방법과 수정 방법까지 함께 정리합니다.

1. NEXT_PUBLIC_ 환경변수 클라이언트 노출

Next.js에서 NEXT_PUBLIC_ 접두어가 붙은 환경변수는 빌드 시 클라이언트 번들에 인라인으로 삽입됩니다. 브라우저 개발자 도구에서 JavaScript 번들을 검색하면 누구나 볼 수 있습니다.

# .env.local — 위험한 예
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxx
NEXT_PUBLIC_DATABASE_URL=postgresql://user:pass@host/db
NEXT_PUBLIC_OPENAI_API_KEY=sk-xxxxxxxxxxxx

# 올바른 방법: 서버 전용 변수는 NEXT_PUBLIC_ 없이 선언
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxx
DATABASE_URL=postgresql://user:pass@host/db
OPENAI_API_KEY=sk-xxxxxxxxxxxx

점검 방법: 배포된 사이트에서 Ctrl+U로 소스 보기 후 NEXT_PUBLIC_으로 검색. 또는 브라우저 개발자 도구 네트워크 탭에서 .js 파일을 열어 API 키 패턴(sk-, Bearer)으로 검색합니다.

• 영향도: API 키 유출 → 무단 과금, 데이터 유출
• 수정: 서버사이드 API Route로 이전, 환경변수에서 NEXT_PUBLIC_ 제거

2. 빌드 로그에 시크릿 노출

Vercel·Netlify의 빌드 로그는 기본적으로 팀 멤버에게 공개됩니다. 빌드 스크립트에서 환경변수를 echo로 출력하거나, 의존성 설치 시 에러 메시지에 인증 토큰이 포함되는 경우가 있습니다.

# package.json — 위험한 예
{
  "scripts": {
    "prebuild": "echo $DATABASE_URL",
    "build": "next build"
  }
}

특히 npm private registry 인증 시 .npmrc에 토큰을 하드코딩하면 빌드 로그에 그대로 출력됩니다.

• 점검: Vercel 대시보드 → 배포 → 빌드 로그 전체 텍스트 검색
• 수정: echo 구문 제거, npmrc 토큰을 환경변수 참조로 변경

3. 보안 헤더 미설정

Vercel·Netlify는 기본적으로 보안 HTTP 헤더를 제공하지 않습니다. Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy를 명시적으로 설정해야 합니다.

// next.config.js
const securityHeaders = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "SAMEORIGIN" },
  { key: "X-XSS-Protection", value: "1; mode=block" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; script-src 'self' 'unsafe-inline';"
  }
];

module.exports = {
  async headers() {
    return [{ source: "/(.*)", headers: securityHeaders }];
  }
};

Netlify는 netlify.toml의 [[headers]] 섹션에서 동일하게 설정합니다.

• 점검: securityheaders.com에서 사이트 URL 입력
• 영향도: XSS, Clickjacking, MIME 스니핑 공격에 취약

4. API Route 인증 누락

Next.js API Route(/api/*)나 Netlify Function은 기본적으로 인터넷에 공개됩니다. 인증 로직이 없으면 누구나 호출할 수 있습니다. 특히 /api/admin, /api/send-email, /api/webhook 같은 민감한 엔드포인트가 인증 없이 노출되는 경우가 많습니다.

// 취약한 예 — 인증 없음
export default function handler(req, res) {
  const users = await db.query("SELECT * FROM users");
  res.json(users);
}

// 올바른 예 — 세션/토큰 검증
export default async function handler(req, res) {
  const session = await getServerSession(req, res, authOptions);
  if (!session) return res.status(401).json({ error: "Unauthorized" });

  const users = await db.query("SELECT * FROM users");
  res.json(users);
}

• 점검: /api/ 하위 엔드포인트를 인증 없이 직접 호출
• 수정: NextAuth, Clerk, 또는 직접 JWT 검증으로 모든 API Route 보호

5. 소스맵 프로덕션 노출

프로덕션 빌드에 소스맵(.js.map)이 포함되면 난독화된 번들의 원본 소스 코드가 공개됩니다. 비즈니스 로직, 내부 API 엔드포인트, 환경변수 키 이름이 그대로 드러납니다.

# next.config.js — 소스맵 비활성화
module.exports = {
  productionBrowserSourceMaps: false  // 기본값 false, 명시적으로 설정
};

Vercel에서 프리뷰 배포는 소스맵을 포함하고 프로덕션 배포는 포함하지 않도록 구분하는 것이 좋습니다. VERCEL_ENV 환경변수로 분기할 수 있습니다.

• 점검: 브라우저 개발자 도구 → Sources 탭에서 원본 파일 구조 확인
• 영향도: 소스 코드 유출, 취약점 탐색 용이

빠르게 점검하는 방법

위 5가지 항목 외에도 Vercel·Netlify 배포 사이트에는 CORS 설정 오류, 공개된 /.git 디렉터리, 만료된 의존성 취약점 등 추가적인 보안 위협이 존재합니다. CodeScan은 URL 하나로 17개 보안 항목을 자동 점검하고 등급과 수정 가이드를 제공합니다. 보안 헤더, 소스맵 노출, 서브도메인 열거까지 한 번에 확인하세요.

지금 무료로 내 사이트 17개 항목 점검하기 →