출시 전 SaaS 보안 체크리스트: 우리가 먼저 실행하는 40가지 항목 (2026)

출시 전 SaaS 보안 체크리스트: 우리가 먼저 실행하는 40가지 항목 (2026)

출시 전 SaaS 보안 체크리스트는 아직 보유하지도 않은 준수 배지 더미보다 훨씬 가치 있습니다. 불편한 진실은 다음과 같습니다. 대부분의 출시 체크리스트는 무엇을 보호해야 하는지 알려줄 뿐, 실제로 어떻게 해야 하는지는 보여주지 않습니다. 이 가이드는 실제 코드를 다룹니다. 우리는 Next.js와 Supabase를 기반으로 구축하며, 단일 tenant_id 필터 누락으로 인해 테스트 계정이 다른 고객의 데이터를 읽게 되는 사례를 목격했습니다. 또한 IBM의 2024년 데이터 유출 비용 보고서에 따르면 글로벌 평균 피해액은 488만 달러에 달합니다. SOC 2 인증이 없어도 서비스를 출시할 수 있습니다. 필요한 것은 아래에 정리된 앱 계층 기본 기준이며, 이는 OWASP 및 NIST 표준에 매핑되어 있습니다.

주요 요약

• SOC 2나 침투 테스트 없이도 출시할 수 있습니다. 아래에 제시된 앱 계층 기본 기준만 갖추면 됩니다.
• 가장 위험한 출시 버그는 tenant_id 확인 누락으로 인한 교차 테넌트 데이터 유출입니다.
• 직접 인증 시스템을 구축하지 마세요. Auth.js, Clerk 또는 Supabase Auth를 사용하세요.
• 배포 전에 NEXT_PUBLIC_ 접두사를 반드시 감사하세요. 이것이 시크릿을 유출하는 가장 빠른 경로입니다.

이 기본 기준은 OWASP ASVS 5.0과 **NIST Secure Software Development Framework (SSDF)**에 매핑됩니다. 이 두 가지는 Google이 이 주제에서 가장 신뢰하는 참조 자료이며, 주목할 점은 상위 랭킹 가이드 중 어느 것도 이를 인용하지 않는다는 사실입니다.

출시 전 보안 체크리스트 (요약 버전)

다음은 배포 전 최소한의 보안 요구 사항으로, 여섯 가지 범주로 분류된 40개 항목입니다. 위에서 아래로 순서대로 실행하고, 코드 섹션을 개발자에게 전달하며, 아래 우선순위 표에서 P0로 표시된 항목은 출시 차단 요소로 간주하세요.

시크릿 및 구성

1. .env 파일은 첫 커밋부터 .gitignore에 포함되며 절대 커밋되지 않았습니다.
2. 모든 NEXT_PUBLIC_ 및 VITE_ 접두사가 감사되었으며, 비밀 정보는 브라우저로 전송되지 않습니다.
3. 서버 시크릿은 저장소가 아닌 관리자(플랫폼 환경 변수, AWS Secrets Manager, Vault 등)에 저장됩니다.
4. git 히스토리에 한 번이라도 노출된 키는 출시 전에 회전(rotated)되었습니다.
5. 로그, 오류 페이로드 또는 클라이언트 번들에 시크릿이 나타나지 않습니다.
6. 빌드된 번들에서 활성 키를 검색했습니다 (grep -r "sk_live" .next/).

인증 및 접근 제어

1. 인증은 직접 구축한 것이 아니라 라이브러리(Auth.js, Clerk 또는 Supabase Auth)를 기반으로 합니다.
2. 계정에서 MFA(다중 인증)를 사용할 수 있습니다.
3. 세션 쿠키에 Secure, HttpOnly 및 SameSite 속성이 설정되었습니다.
4. JWT 또는 세션 토큰이 localStorage에 저장되지 않습니다.
5. RBAC(역할 기반 접근 제어) 및 최소 권한 원칙이 UI 숨김이 아닌 서버 측에서 강제됩니다.
6. 비밀번호는 Argon2 또는 bcrypt로 해싱됩니다(자체 인증 관리 시에만 해당).
7. 비밀번호 재설정 및 이메일 검증 흐름이 남용에 대해 테스트되었습니다.

데이터 및 테넌시

1. 모든 쿼리에 tenant_id 필터가 포함되어 있습니다.
2. 테넌트 스코핑은 쿼리마다 기억하는 것이 아니라 ORM 또는 리포지토리 계층에서 강제됩니다.
3. 행 수준 보안(RLS)이 활성화되었으며 실패 모드가 이해되었습니다.
4. 모든 객체 ID 엔드포인트에서 소유권 검사를 수행합니다(IDOR 방지).
5. tenant_id가 캐시 키 및 객체 스토리지 경로에 포함됩니다.
6. 데이터는 저장 시 및 전송 중에 암호화됩니다.
7. 결제 및 웹훅 서명(Stripe 등)이 서버 측에서 검증됩니다.

의존성 및 공급망

1. npm audit 또는 pnpm audit 결과가 높음(high) 및 중요(critical) 등급에서 깨끗하거나 명시적으로 triage되었습니다.
2. Dependabot 또는 Renovate가 활성화되었습니다.
3. Snyk 또는 Socket을 사용하여 더 깊은 SCA(소프트웨어 구성 분석) 및 맬웨어, 라이선스 검사를 수행합니다.
4. lockfile이 커밋되었습니다.
5. 핵심 경로에 버려지거나 유지보수되지 않는 패키지가 없습니다.
6. Docker를 배포하는 경우 컨테이너 이미지가 스캔되었습니다.

네트워크 및 전송

1. HSTS 프리로드와 함께 모든 곳에서 HTTPS가 강제됩니다.
2. 콘텐츠 보안 정책(CSP)이 설정되었습니다(처음에는 report-only 모드, 이후 enforce 모드).
3. X-Content-Type-Options: nosniff 및 X-Frame-Options/frame-ancestors가 설정되었습니다.
4. Referrer-Policy 및 Permissions-Policy가 설정되었습니다.
5. CORS는 허용 목록을 사용하며 자격 증명과 함께 *를 사용하지 않습니다.
6. 속도 제한(rate limiting)이 인증 및 비용이 많이 드는 엔드포인트를 보호합니다.
7. 모든 엔드포인트가 스키마(Zod 등)를 사용하여 입력을 검증합니다.

모니터링 및 대응

1. 중앙 집중식 감사 로그가 누가 언제 무엇에 접근했는지 기록합니다.
2. 오류 처리가 사용자에게 스택 추적 정보를 유출하지 않습니다.
3. 인증 이상 징후(로그인 실패 급증, 불가능한 이동 경로 등) 발생 시 알림이 발송됩니다.
4. 자동 백업이 실행되며 복원 테스트를 완료했습니다.
5. 인시던트 대응 연락처와 원페이지 런북(runbook)이 존재합니다.
6. 가동 시간 및 오류 모니터링(Sentry 또는 동급 도구)이 활성화되었습니다.
7. 침투 테스트를 도입해야 하는 트리거 조건을 알고 있습니다.

우선 수정 대상

모든 항목이 출시를 차단하는 것은 아닙니다. 이 삼분표(triage table)는 건너뛰었을 때의 피해 규모에 따라 기본 기준을 정렬하므로, 창업자는 어떤 것이 필수 불가결한지 알 수 있습니다. P0 = 출시 전 수정, P1 = 첫 주 내 수정, P2 = 분기 내 수정.

시크릿 및 구성: 클라이언트 번들로 키가 유출되고 있나요?

출시 시의 시크릿 위생이란 어떠한 자격 증명도 브라우저에 도달하지 않도록 하는 것을 의미합니다. Next.js의 NEXT_PUBLIC_ 접두사(및 Vite의 VITE_)는 값을 모든 방문자에게 전송하므로, 잘못된 접두사 하나가 키를 유출시킵니다. .env 파일을 git에서 제외하고, 서버 시크릿은 관리자에 보관하며, 배포 전에 빌드 출력을 grep으로 검색하세요.

우리가 가장 자주 보는 함정은 다음과 같습니다: NEXT_PUBLIC_는 "공개 정보"를 의미하지 않습니다. 이는 "내가 이 값을 모든 방문자의 브라우저로 literally 전송한다"는 뜻입니다. Stripe 시크릿이나 서비스 역할 키에 이러한 접두사를 붙이면 DevTools를 열 수 있는 누구나 번들에서 이를 볼 수 있게 됩니다.

# .env.local (the mistake)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # BAD: ships to every browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: server-only

# Public (safe to expose) vs server-only
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon key is meant to be public
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # never NEXT_PUBLIC_ this

# Catch a leaked key before you deploy
grep -r "sk_live" .next/    # any hit means a secret is in your client bundle

나머지 시크릿 기본 기준은 지루하지만 필수적입니다: 첫 커밋부터 .gitignore에 .env 포함, 저장소가 아닌 관리자에 서버 시크릿 보관, git 히스토리에 한 번이라도 닿았던 키의 회전(커밋 삭제는 유출을 취소하지 않습니다). 유출된 배포 토큰은 바로 Vercel 해킹 사건과 같은 침해 사고가 시작되는 방식이므로, 모든 토큰을 이미 누군가의 감시 목록에 올라간 것처럼 취급하세요.

인증 및 접근 제어: 인증을 직접 구축해야 할까요, 라이브러리를 사용해야 할까요?

인증 시스템을 직접 구축해야 할까요, 아니면 라이브러리를 사용해야 할까요? 거의 항상 라이브러리를 사용하세요. Auth.js, Clerk 및 Supabase Auth는 프로덕션 환경에서 다시 발견하게 될 세션 고정, 토큰 폐기, 재설정 흐름 남용 등 수년간의 엣지 케이스를 흡수했습니다. 보안 엔지니어가 있고 어떤 제공자도 적합하지 않은 특별한 이유가 없는 한, 직접 구축하는 것은 정당화하기 어렵습니다.

직접 인증을 구축하는 것은 월 25달러를 절약하기 위한 가장 비싼 방법입니다. 현실적인 옵션들의 비교는 다음과 같습니다.

라이브러리를 선택하지만 구성을 건너뛰는 팀들을 좌절시키는 두 가지 함정이 있습니다. 첫째, JWT 폐기는 정말 어렵기 때문에 탈취된 토큰은 만료될 때까지 유효합니다. 토큰 수명을 짧게 유지하고 민감한 정보에는 서버 측 세션을 선호하세요. 둘째, localStorage의 토큰은 모든 XSS 페이로드에 의해 탈취될 수 있으므로, Secure 및 SameSite 속성이 있는 httpOnly 쿠키에 세션을 저장하세요. UI에서 버튼을 숨기는 것이 아닌 서버에서 RBAC를 강제하세요.

SaaS가 AI 또는 LLM 기능을 제공하는 경우, 모델 입력도 신뢰할 수 없는 인증 경계로 취급하세요. 프롬프트 인젝션 방지 가이드를 참조하세요. 도구에 접근 가능한 탈옥된 어시스턴트는 채팅 창을 쓴 접근 제어 문제이기 때문입니다.

데이터 및 테넌시: 한 테넌트가 다른 테넌트의 데이터를 읽지 못하도록 어떻게 막을까요?

테넌트 격리란 모든 쿼리, 캐시 키 및 스토리지 경로가 현재 테넌트로 스코핑된다는 것을 의미합니다. tenant_id 필터 누락은 한 고객이 다른 고객의 데이터를 읽게 하며, 이는 존재하는 가장 위험한 출시 버그입니다. 행 수준 보안(RLS)은 도움이 되지만 방탄복이 아닌 안전벨트와 같으므로, 모든 객체 ID 엔드포인트에도 소유권 검사를 추가하세요.

이는 경쟁사들이 코드로 다루지 않는 섹션이며, 교차 테넌트 유출이 프로덕션으로 slipping 되는 이유입니다. 해결책은 ID를 단독으로 신뢰하지 않는 것에서 시작됩니다. 모든 읽기를 호출자의 테넌트로 스코핑하고, 쿼리마다 기억할 필요가 없도록 데이터 계층에서 이를 강제하세요.

// BAD: no tenant scope. Any valid id returns any tenant's row.
const order = await db.order.findFirst({ where: { id } });

// GOOD: scoped to the caller's tenant on every read.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

관련된 실패는 IDOR(불안전한 직접 객체 참조)이며, OWASP API Security Top 10에서는 API1: Broken Object Level Authorization으로 분류합니다. 테스트 계정이 URL의 ID를 증가시켜서는 안 볼 기록을 읽습니다. PortSwigger의 Web Security Academy에는 공격자가 이를 찾는 방법에 대한 전체 walkthrough가 있습니다. 해결책은 하나의 소유권 검사입니다.

// GET /api/invoices/1234, a test account increments the id
// and reads another tenant's invoice. Classic BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: verify ownership before you return anything.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

정직함을 유지하게 하는 프레임워크는 다음과 같습니다: 모든 IDOR는 테넌트 격리 실패이지만, 모든 테넌트 격리 실패가 IDOR는 아닙니다. Postgres 행 수준 보안은 데이터베이스에서 많은 사례를 잡아내지만, 이에 의존하기 전에 알아야 할 묵시적 실패 모드가 있습니다.

-- Postgres RLS: a seatbelt, not a force field.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Silent-failure trap: forget to SET app.tenant_id on a pooled
-- connection and the policy reads the PREVIOUS request's tenant.

연결 풀 오염, 비동기 컨텍스트 누수 및 공유 캐시 poisoning은 모두 RLS를 조용히 무력화시키므로, OWASP Multi-Tenant Security Cheat Sheet에서는 캐시 키와 스토리지 경로에도 테넌트 접두사를 붙일 것을 권장합니다. 여기서 전체를 읽을 가치가 있는 두 가지 참조 자료는 OWASP ASVS 5.0의 접근 제어 챕터와 Supabase RLS 문서입니다.

의존성 및 공급망: node_modules에 무엇이 숨어 있을까요?

앱의 안전성은 가장 약한 전달 의존성과 동일합니다. CI에서 npm audit 또는 pnpm audit를 실행하고, 출시 전에 높음 또는 중요 등급 발견 시 빌드를 실패 처리하세요. 자동 업데이트를 위해 Dependabot 또는 Renovate를 추가하고, 더 깊은 맬웨어 및 라이선스 검사를 위해 Snyk 또는 Socket을 사용하세요.

함정은 수동으로 한 번 감사를 실행하고 초록색 결과를 본 후 다시는 실행하지 않는 것입니다. CI에 연결하여 사용자가 건드리지 않은 패키지의 새로운 CVE라도 병합을 차단하도록 하세요.

# .github/workflows/ci.yml: block the merge on high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # non-zero exit fails the job

npm audit 문서는 심각도 수준과 개발 전용 발견 사항을 무시하려는 경우 --production 플래그를 다룹니다. 자동 스캐닝은 기본 요건이지만, 의존성 스캐너가 놓치는 코드 냄새와 인젝션 경로를 잡아내는 더 깊은 정적 분석을 위해서는 SonarQube 리뷰를 참조하세요. lockfile을 커밋하고, 수년 동안 릴리스되지 않은 패키지를 제거하며, Docker를 배포하는 경우 컨테이너 이미지를 스캔하세요.

네트워크 및 전송: SaaS에 실제로 필요한 보안 헤더는 무엇일까?

SaaS에 필요한 보안 헤더는 무엇일까요? HTTPS plus HSTS와 짧은 헤더 세트가 가장 쉽게 악용될 수 있는 격차를 닫습니다. Content-Security-Policy, 와일드카드 대신 CORS 허용 목록, 그리고 인증 및 비용이 많이 드는 엔드포인트에 속도 제한을 추가하세요. Zod와 같은 스키마로 모든 입력을 검증하여 나쁜 페이로드가 로직에 도달하지 못하도록 하세요.

발명된 모든 헤더가 필요하지 않습니다. 이 짧은 목록만 필요하며, MDN 보안 헤더 참조에서 각각을 자세히 설명합니다.

헤더를 엣지에서 한 번 설정하고, 스크립트가 로그인 루트를 밤새 무차별 대입 공격하지 못하도록 속도 제한기를 추가하세요.

// next.config.js: security headers on every response
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate-limit auth routes (Upstash example)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

앱을 깨뜨리지 않도록 CSP를 report-only 모드로 시작한 다음, 며칠 동안 위반 보고서를 모니터링한 후 enforce 모드로 전환하세요. CORS는 이름이 지정된 허용 목록으로 제한하고, 자격 증명과 함께 *를 절대 쌍으로 사용하지 마세요.

모니터링 및 대응: 침해 사고가 발생했음을 어떻게 알 수 있을까?

볼 수 없는 것에 대응할 수는 없습니다. 출시 전에 중앙 집중식 감사 로그, 로그인 실패 급증과 같은 인증 이상 징후 알림, 테스트된 복원이 포함된 자동 백업, 그리고 원페이지 인시던트 런북을 연결하세요. 테스트되지 않은 백업은 백업이 아닌 희망일 뿐이며, 런북을 작성할 시점은 인시던트 중간이 아닌 지금입니다.

IBM의 데이터에 따르면 침해 사고를 식별하고 통제하는 데 평균 258일이 소요되며, 로그가 누가 무엇에 접근했는지 기록하지 않으면 이 숫자를 줄일 수 없습니다. 로그를 중앙화하고 중요한 이상 징후(로그인 실패 급증, 불가능한 이동 경로 로그인, 갑작스러운 대량 export)에 알림을 설정하며, 오류 핸들러가 내부 구조를 드러내는 스택 추적이 아닌 깔끔한 메시지를 반환하도록 하세요.

현대적인 침해 탐지는 정적 규칙보다는 이상 징후 모니터링에 의존합니다. 이것이 실제로 어떻게 작동하는지에 대한 자세한 내용은 AI가 데이터 유출을 방지하는 방법 기사를 참조하세요. 프레임워크 배경으로는 NIST SSDF (SP 800-218)가 대응 및 모니터링 관행을 평이한 언어로 제시합니다. 데이터베이스가 사라진 후에 아니라 출시 전에 복원을 테스트하세요.

실제 출시 검토 시 우리가 발견하는 것

우리 팀이 자체 빌드나 고객 빌드에 대해 출시 전 보안 점검을 수행할 때, 다른 것보다 두 가지 누락 사항이 더 자주 나타납니다. 첫째: NEXT_PUBLIC_ 접두사를 통해 브라우저로 진입하는 시크릿으로, 보통 클라이언트 측 호출을 작동시키기 위해 누군가가 접두사를 붙인 서드파티 API 키입니다. 둘째: tenant_id 스코프 또는 소유권 검사가 누락된 최소 하나의 엔드포인트입니다.

테넌트 스코프 누락은 앱이 정상적으로 보이기 때문에 무서운 버그입니다. 모든 페이지가 로드됩니다. 이 버그는 누군가 URL의 ID를 변경할 때만 나타납니다. 한 리뷰에서 GET /api/orders/:id는 로그인한 모든 사용자에게 모든 주문을 반환했으며, 테스트 계정이 숫자를 증가시켜 다른 테넌트의 주문을 읽었습니다. 해결책은 두 줄이었습니다: 반환 전에 order.tenantId와 session.tenantId를 비교하는 것입니다.

여기서 가짜 발견률을 인용하지는 않겠습니다. 정직하고 반복 가능한 사실은 다음과 같습니다: NEXT_PUBLIC_ 유출과 누락된 테넌트 스코프는 거의 모든 1차 통과 리뷰에서 발견되는 두 가지 사항이며, 둘 다 찾아야 할 곳을 알면 수정 비용이 저렴합니다. 이것이 바로 체크리스트가 이들을 P0로 최우선 배치하는 이유입니다.

출시일 전에 팀이 이 점검을 대신 수행해주길 원한다면, 그것이 우리가 하는 일입니다. 출시 전 보안 검토 받기 →

저자 소개

Mert Batur Gurbuz는 Techsy.io의 공동 창업자로, 팀은 B2B 고객을 위한 AI 에이전트, 자동화 시스템 및 음성/SDR 파이프라인을 제공합니다. 그는 버밍엄 대학교에서 공부하며 Techsy 팀이 프로덕션에서 실제로 사용하는 LLM 툴링 스택에 대해 글을 씁니다. LinkedIn에서 연결하세요.

자주 묻는 질문

출시 전 SaaS 보안 체크리스트에는 무엇이 포함되어야 하나요?

여섯 가지 카테고리: 시크릿 및 구성(키를 클라이언트 번들에서 제외), 인증 및 접근 제어(라이브러리 사용, MFA 추가), 데이터 및 테넌시(tenant_id 스코핑 및 소유권 검사), 의존성(CI에서의 npm audit), 네트워크 및 전송(HTTPS, HSTS, CSP, 속도 제한), 모니터링 및 대응(감사 로그, 테스트된 백업, 런북).

내 SaaS는 출시할 만큼 안전한가요?

P0 기본 기준이 완료되면 준비되었습니다: 클라이언트 번들에서 시크릿 제거, 모든 쿼리의 테넌트 격리, 라이브러리 기반 인증, 보안 헤더가 포함된 HTTPS, 그리고 깨끗한 의존성 스캔. 완벽함이 기준은 아닙니다. 기본 기준을 갖춘 출시되고 모니터링되는 앱이 출시되지 않는 "완벽한" 앱보다 낫습니다.

SaaS 출시 전에 침투 테스트가 필요한가요?

법적으로 출시하기 위해 필수 사항은 아닙니다. 결제 또는 개인 식별 정보(PII)를 처리하거나, 엔터프라이즈 구매자를 대상으로 하거나, 감사관 또는 투자자가 요청하는 경우 우선순위를 두세요. MVP 단계에서는 그 노력을 앱 계층 기본 기준과 OWASP Top 10에 먼저 투입하세요. 명백한 IDOR 및 헤더 격차가 이미 닫혀 있을 때 침투 테스트는 더 많은 것을 찾아냅니다.

SaaS 출시 위해 SOC 2가 필요한가요?

아닙니다. 지난주에 출시한 스타트업에게 SOC 2를 기대하는 고객은 없습니다. 이는 출시 게이트가 아닌 엔터프라이즈 영업 해제 수단이며, 몇 달이 걸립니다. 앱 계층 기본 기준으로 출시한 후, 실제 엔터프라이즈 거래가 필요할 때 SOC 2 프로세스를 시작하세요. 그 이전에는 아닙니다.

Auth.js, Clerk 또는 Supabase Auth와 같은 라이브러리를 사용해야 할까요, 아니면 자체 인증을 구축해야 할까요?

거의 항상 라이브러리를 사용하세요. Auth.js, Clerk 및 Supabase Auth는 자체 구축 인증 버그의 대부분을 유발하는 세션, 토큰 및 재설정 흐름 엣지 케이스를 처리했습니다. 보안 엔지니어가 있고 어떤 제공자도 충족하지 못하는硬性 요구 사항이 있는 경우에만 직접 구축하는 것이 정당화되며, 이는 정말 드뭅니다.

클라이언트 번들에서 시크릿을 어떻게 보호하나요?

모든 NEXT_PUBLIC_ 및 VITE_ 접두사를 감사하세요. 해당 접두사가 있는 모든 것은 브라우저로 전송되기 때문입니다. 첫 커밋부터 git에서 .env를 제외하고, 서버 시크릿을 관리자에 저장하며, 배포 전에 빌드된 번들을 grep(grep -r "sk_live" .next/)하여 유출된 키를 잡아내세요.

다중 테넌트 SaaS에서 테넌트 데이터를 어떻게 격리하나요?

모든 쿼리에 tenant_id 필터를 넣고 ORM 또는 리포지토리 계층에서 강제하여 자동화되도록 하세요. 행 수준 보안을 활성화하고 실패 모드(풀 오염, 비동기 누수)를 학습하세요. IDOR를 차단하기 위해 모든 객체 ID 엔드포인트에 소유권 검사를 추가하고, 캐시 키와 스토리지 경로를 테넌트별로 스코핑하세요.

출시 전 SaaS에 필요한 보안 헤더는 무엇인가요?

최소한: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options 또는 frame-ancestors, Referrer-Policy 및 Permissions-Policy. CSP를 report-only 모드로 시작하여 위반 사항을 검토한 후 적용하세요. MDN 보안 헤더 문서에는 각 헤더의 권장 값이 나열되어 있으며, 위의 헤더 표는 각 헤더가 차단하는 내용을 요약합니다.

npm audit 또는 Snyk와 같은 자동 스캐닝으로 충분한가요?

필수적이지만 충분하지는 않습니다. npm audit, Snyk 및 Socket과 같은 도구는 알려진 CVE 및 악성 패키지를 잡아내지만, IDOR 또는 누락된 테넌트 스코프와 같은 비즈니스 로직 및 접근 제어 결함은 찾을 수 없습니다. 이러한 문제는 사람, 테스트 계정 및 명시적인 소유권 검사가 필요합니다. 스캐너와 수동 점검을 모두 실행하세요.

결론: 실제로 출시할 수 있는 SaaS 보안 체크리스트

출시를 위해 완벽할 필요는 없습니다. 기본 기준만 필요합니다. P0 항목을 먼저 닫으세요: 번들에서 시크릿 제거, 모든 쿼리의 테넌트 격리, 모든 객체 엔드포인트의 소유권 검사, 라이브러리 기반 인증, 그리고 헤더가 포함된 HTTPS. 금요일 출시 전에 한 가지만 수정해야 한다면 테넌트 격리로 만드세요. 경고 없이 고객 데이터를 유출하는 버그이기 때문입니다.

여기의 모든 내용은 오늘 바로 실행 가능하며, 준수 예산이 필요하지 않습니다. 40가지 점검 항목을 진행하고, 코드 섹션을 개발자에게 전달한 후 출시하세요. 라이브 가기 전에 제2의 눈을 원하시나요? 무료 상담 받기를 통해 목록을 함께 살펴보세요.