바이브 코딩과 보안

• 개인정보를 덜 모으고, 서버에서 권한을 확인하고, 키를 브라우저에 넣지 않는 세 가지만 먼저 잡는다.
• 체크리스트 섹션의 “공개 전 30분”과 “수동 10분 테스트”를 실제 브라우저와 계정 2개로 따라 한다.
• 어려운 용어는 뒤의 키워드 사전에서 먼저 확인하고, 모든 항목을 한 번에 완벽히 하려고 하지 않는다.

• 데이터 지도, 시크릿 관리, 인증/인가/RLS, 로그와 사고 대응을 최소 운영 체계로 만든다.
• Supabase, D1, Turso, VPS Postgres 중 현재 쓰는 저장소의 “안전한 사용선”을 기준으로 배포 전 테스트를 한다.
• AI에게 기능 구현을 맡긴 뒤에는 반드시 별도 대화에서 악용 시나리오와 방어 검증만 시킨다.

• OWASP Top 10을 단순 매핑표가 아니라 ASVS, API Top 10, LLM Top 10, NIST SSDF, 사고 대응까지 연결한다.
• source에서 sink까지 데이터 흐름을 추적하고, “방어 확인”, “취약 확인”, “판단 불가”로만 결론을 낸다.
• Critical/High 수정 뒤 회귀 테스트와 로그 기반 탐지까지 확인해야 완료로 본다.

• 만 14세 미만 아동의 개인정보를 동의 기반으로 처리한다면 법정대리인 동의와 동의 확인 절차가 필요한지 검토한다.
• 아동에게 개인정보 처리 내용을 알릴 때는 이해하기 쉬운 문장과 화면을 사용한다.
• 주민등록번호는 법령 근거 없이 수집하지 않는다. 본인확인이 필요하면 휴대전화, 아이핀, 인증서 등 대체수단을 우선 검토한다.
• 연령 확인, 법정대리인 동의, 본인확인 흐름은 필요한 최소 정보만 받고, 실패하거나 동의가 확인되지 않으면 보존 기간과 파기 절차를 정한다.

• 주문 확인, 보안 알림, 비밀번호 재설정 같은 정보성 메시지와 이벤트, 할인, 신상품 안내 같은 광고성 메시지를 분리한다.
• 광고성 이메일, 문자, 앱푸시는 수신자의 명시적 사전 동의와 수신거부/동의철회 경로를 갖춘다.
• 오후 9시부터 다음 날 오전 8시까지 광고성 정보를 전송하려면 별도 사전 동의가 필요한지 확인한다.
• 메일/SMS 발송 시스템은 인증 코드 brute force뿐 아니라 발송 폭주, 피싱 악용, 수신거부 미반영, bounce/complaint 증가도 모니터링한다.

• API1 Broken Object Level Authorization
• API2 Broken Authentication
• API3 Broken Object Property Level Authorization
• API4 Unrestricted Resource Consumption
• API5 Broken Function Level Authorization
• API6 Unrestricted Access to Sensitive Business Flows
• API7 Server Side Request Forgery
• API8 Security Misconfiguration
• API9 Improper Inventory Management
• API10 Unsafe Consumption of APIs

바이브 코딩 앱은 화면보다 API가 먼저 뚫린다. 객체 ID, 속성, 함수, 비즈니스 흐름 권한을 서버에서 모두 확인해야 한다.

• Improper Credential Usage
• Inadequate Supply Chain Security
• Insecure Authentication and Authorization
• Insufficient Input and Output Validation
• Insecure Communication
• Inadequate Privacy Controls
• Insufficient Binary Protections
• Security Misconfiguration
• Insecure Data Storage
• Insufficient Cryptography

모바일 앱을 함께 만들면 기기 저장소, API 키, 앱 권한, 바이너리 분석, 통신 보안까지 봐야 한다. 앱 안의 키는 결국 보인다고 생각해야 한다.

• LLM01 Prompt Injection
• LLM02 Sensitive Information Disclosure
• LLM03 Supply Chain
• LLM04 Data and Model Poisoning
• LLM05 Improper Output Handling
• LLM06 Excessive Agency
• LLM07 System Prompt Leakage
• LLM08 Vector and Embedding Weaknesses
• LLM09 Misinformation
• LLM10 Unbounded Consumption

LLM은 검색창이 아니라 판단하고 도구를 부르는 실행면이다. 프롬프트, 검색 결과, 파일, 웹페이지, 다른 사용자 입력을 모두 적대적 입력으로 봐야 한다.

• `.env`, `.env.local`, production secret은 Git에 커밋하지 않는다.
• `.env.example`에는 실제 값이 아니라 placeholder만 둔다.
• Vercel, Cloudflare, Railway, GitHub Actions의 Production, Preview, Development secret을 분리한다.
• Dockerfile에 `ENV API_KEY=...`나 `COPY .env .`를 넣지 않는다.
• Slack, Notion, Google Drive, Figma, 이슈, 스크린샷, 커뮤니티 질문에도 키가 남지 않게 검색한다.

• Git 히스토리에 키가 들어갔다면 `.gitignore` 추가만으로 끝나지 않는다. 키를 즉시 폐기하고 새로 발급한다.
• gitleaks, trufflehog, GitHub secret scanning으로 전체 히스토리를 확인한다.
• 히스토리 정리는 BFG나 git filter-repo를 쓰되, 이미 노출된 키는 무조건 교체한다.
• CI 로그, 빌드 로그, 에러 로그에 `${{ secrets.* }}` 값이 출력되지 않게 masking을 확인한다.
• 오래된 키, 미사용 키, 권한이 큰 키는 정기적으로 폐기한다.

• service_role, DB password, Cloudflare API token, Turso token은 서버 전용으로 둔다.
• 읽기 전용, 특정 조직, 특정 DB, 특정 bucket, 특정 branch 등 scope를 줄인다.
• 공유 계정 키보다 개인별 또는 서비스별 키를 사용해 추적 가능하게 한다.
• 키 회전 주기와 비상 회전 절차를 문서화한다.
• AI 코딩 도구나 agent에게 production secret을 주지 않는다.

• 민감 토큰은 localStorage보다 HttpOnly, Secure, SameSite 쿠키를 우선 검토한다.
• HttpOnly 쿠키가 XSS를 완전히 막는 것은 아니므로 CSP, 입력 검증, 출력 인코딩을 같이 둔다.
• 세션 ID와 토큰은 URL query, fragment, referer, 로그에 남기지 않는다.
• 로그인 직후, 권한 상승, MFA 통과, 관리자 전환 후에는 세션 ID를 재발급해 session fixation을 막는다.
• JWT payload는 암호화가 아니라 인코딩이다. 비밀번호, 주민번호, 결제 정보, 내부 권한 구조를 넣지 않는다.
• JWT 검증은 `alg` allowlist, issuer, audience, expiry, clock skew, `kid` 처리 정책을 고정하고 `alg=none`과 HS256/RS256 혼동을 차단한다.
• access token은 짧게, refresh token은 rotation과 재사용 탐지를 적용한다.
• refresh token은 원문 저장을 피하고 서버 저장 해시, token family, 재사용 탐지 시 전체 family 폐기를 검토한다.
• 로그아웃, 비밀번호 변경, MFA 변경, 권한 변경, 탈퇴 후 기존 세션과 refresh token을 무효화한다.
• 쿠키 Domain은 넓게 잡지 말고 Path, Max-Age, `__Host-` prefix, Clear-Site-Data 적용 가능성을 확인한다.
• 토큰, OTP, reset code, webhook 서명 비교는 일반 문자열 비교가 아니라 timing-safe comparison을 검토한다.
• 세션 ID, reset token, OTP secret은 CSPRNG로 만들고 `Math.random()` 같은 예측 가능한 난수는 쓰지 않는다.

• 비밀번호는 Argon2id, bcrypt, scrypt 같은 느린 KDF로 저장한다. SHA-256 단독 해시는 금지한다.
• bcrypt는 72바이트 입력 제한을 알고 긴 passphrase 정책을 설계한다.
• 재설정 token은 1회용, 짧은 만료, 재사용 불가, 서버 저장 해시로 관리한다.
• 비밀번호 재설정 응답은 계정 존재 여부를 노출하지 않는다.
• 재설정 링크는 Host 헤더로 만들지 말고 고정된 서비스 URL 기준으로 만든다.
• 비밀번호 변경, 이메일 변경, MFA 해제, 계정 복구에는 최근 로그인 또는 재인증을 요구한다.
• 재설정 token, 이메일 인증 token, magic link는 access log와 analytics URL에 남지 않게 한다.
• 비밀번호 재설정, magic link, 이메일 인증 요청은 계정, IP, 기기, 세션 단위 rate limit과 resend cooldown을 둔다.
• 비밀번호 재설정 성공 후 자동 로그인하지 말고, 기존 세션 정리와 보안 알림을 보낸다.

• 로그인, OTP, MFA, 비밀번호 재설정, 이메일 인증 코드 검증은 시도 횟수 제한, 점진적 지연, 위험 기반 CAPTCHA를 둔다.
• lockout은 계정 마비 공격으로 악용될 수 있으므로 짧은 임시 잠금, 단계적 지연, 사용자 알림, 관리자 해제 절차를 같이 설계한다.
• credential stuffing 방어를 위해 유출 비밀번호 재사용 탐지, 의심 로그인 알림, 새 기기 추가 인증, MFA 권장을 적용한다.
• OTP와 이메일/SMS 코드는 짧은 만료, 재전송 시 이전 코드 폐기, 검증 실패 횟수 제한, 서버 저장 해시를 적용한다.
• 인증 실패 로그는 이메일 전체와 입력한 비밀번호를 남기지 말고, IP/ASN/device/user-agent 기반 이상 징후를 집계한다.

• 관리자, 배포자, 결제 관리자, DB 운영자 계정에는 MFA를 필수로 둔다.
• 가능하면 SMS보다 인증 앱, 더 가능하면 FIDO2/WebAuthn 같은 phishing-resistant 방식을 검토한다.
• 관리자 세션은 일반 사용자보다 짧은 유휴 만료와 절대 만료를 둔다.
• 관리자 로그인 성공, 새 기기 로그인, 권한 변경은 별도 알림을 보낸다.
• super_admin 수를 줄이고 역할을 콘텐츠, 사용자, 시스템, 재무 등으로 나눈다.

• 계정 복구와 인증 메일 발송 도메인은 SPF, DKIM, DMARC를 설정하고 서비스 도메인과 발송 도메인의 신뢰 경계를 문서화한다.
• reset link, magic link, 초대 링크에 `next`, `returnTo`, `redirect`가 붙는다면 같은 origin 또는 서버 allowlist만 허용한다.
• 알림 메일의 링크는 추적용 redirect를 거치더라도 최종 목적지를 검증하고, 피싱처럼 보이는 단축 URL을 피한다.
• 이메일/SMS 발송 API는 남용되기 쉬우므로 발송량 quota, resend cooldown, 수신자별 제한, bounce/complaint 모니터링을 둔다.
• 광고성 이메일, 문자, 카카오 알림은 정보성 메시지와 분리하고 수신 동의, 수신거부, 야간 전송 별도 동의 여부를 확인한다.

• 관리자 라우트는 일반 사용자 라우트와 같은 guard 하나로 끝내지 말고 별도 middleware, 별도 세션 정책, 별도 audit log를 둔다.
• 관리자 계정에는 MFA를 필수로 적용하고, 가능하면 FIDO2/WebAuthn 같은 phishing-resistant 인증을 우선한다.
• JWT payload의 `role: admin`만 믿지 말고 서명, issuer, audience, 만료, 서버 DB의 현재 권한을 함께 확인한다.
• 관리자 세션은 일반 세션보다 짧은 유휴 만료와 절대 만료를 두고 권한 변경, 비밀번호 변경, MFA 변경 후 재인증을 요구한다.
• 관리자 로그인 실패, 새 기기 로그인, 새 관리자 생성, 권한 상승은 즉시 알림을 보낸다.

• `/admin` 경로 숨김, robots 차단, 메뉴 숨김은 보안이 아니라 힌트 감소에 불과하다.
• 관리자 API는 role뿐 아니라 대상 리소스, tenant, 조직, plan, 업무 범위를 서버에서 다시 검증한다.
• 가능하면 Cloudflare Access, VPN, Tailscale, Zero Trust, IP allowlist 같은 접속 경로 보호를 겹친다.
• IP allowlist는 보조 방어선이다. 재택, 모바일, VPN, 프록시 환경을 고려하되 인증과 인가를 대체하지 않는다.
• 관리자 export, 사용자 조회, 결제 상태 변경, 권한 변경은 별도 role과 승인 흐름을 둔다.

• 누가, 언제, 어떤 IP/기기에서, 어떤 관리자 기능으로, 어떤 대상 리소스를, 어떻게 바꿨는지 남긴다.
• 대량 조회, 대량 export, 권한 변경, 결제 상태 변경, 설정 변경은 변경 전/후를 마스킹된 형태로 기록한다.
• 감사 로그에는 비밀번호, 토큰, reset token, 카드번호 원문을 남기지 않는다.
• 관리자 로그는 일반 앱 로그보다 변조 위험이 크므로 별도 저장소, 보존 기간, 접근 권한을 둔다.
• 관리자 기능 배포 전에는 일반 사용자 계정, 탈퇴 계정, 권한 없는 관리자 계정으로 직접 접근 테스트를 한다.

• Content-Type, Content-Length, body size, field allowlist를 검증한다.
• SQL은 parameter binding을 쓰고 column, order, table 이름처럼 binding 불가한 값은 allowlist로 제한한다.
• JSON body 전체를 DB update에 넣지 않는다. role, plan, user_id 같은 서버 관리 필드는 무시한다.
• 외부 URL, redirect URL, file path, command argument, template name, LLM tool argument는 각각 별도 allowlist를 둔다.
• 로그인 후 이동, OAuth callback, 이메일 링크의 `next`, `returnTo`, `redirect`는 open redirect로 보고 상대 경로 또는 서버 매핑 ID만 허용한다.

• CORS는 필요한 origin만 허용한다. CORS를 인증이나 권한 통제라고 착각하지 않는다.
• 쿠키 인증을 쓰는 상태 변경 API는 CSRF token, Origin/Referer, SameSite, Fetch Metadata 중 최소 하나 이상을 서버에서 검증한다.
• 서버가 URL을 fetch하는 기능은 SSRF로 본다. `localhost`, private IP, link-local, metadata IP, redirect, DNS rebinding을 차단한다.
• 웹훅 endpoint는 CORS 대상이 아니다. raw body 서명, timestamp, event id, provider allowlist로 검증한다.

• HTML, Markdown, rich text, LLM 출력은 렌더링 전 sanitizer와 escaping을 적용한다.
• API 응답에는 화면에 필요한 필드만 내려준다.
• 오류 응답에는 stack trace, DB 테이블명, 내부 경로, 라이브러리 버전을 노출하지 않는다.
• redirect URL은 같은 origin 또는 allowlist만 허용하고, 허용 후에도 최종 URL을 canonicalize해서 검증한다.

• 파일명은 서버에서 새로 만든다. 사용자 파일명과 경로를 그대로 쓰지 않는다.
• 크기 제한, 확장자 allowlist, MIME 검증, magic byte 검증, 이미지 재인코딩, EXIF 제거를 검토한다.
• SVG, HTML, JS, 실행 파일은 public 업로드 경로에 두지 않는다.
• 업로드 파일은 실행 불가 저장소에 두고 public 서빙 도메인과 앱 쿠키 도메인을 분리한다.
• 다운로드 API에서 `../`, 절대경로, 숨김 파일 접근이 불가능한지 테스트한다.

• `NEXT_PUBLIC_`이 붙은 값은 공개 정보라고 본다. secret, service key, DB URL을 넣지 않는다.
• 서버 컴포넌트에서 클라이언트 컴포넌트로 user 객체 전체를 넘기지 않는다.
• Network 응답에 화면에서 쓰지 않는 이메일, role, internal id, 결제 정보, token이 내려오지 않는지 본다.
• 프로덕션 source map, debug route, test fixture, sample JSON이 public 경로에 없는지 확인한다.
• `robots.txt`로 `/admin`을 숨기는 것은 보안이 아니다. 오히려 경로 힌트가 될 수 있다.
• 로그아웃 시 localStorage, sessionStorage, IndexedDB, Service Worker cache, in-memory store에 남은 개인정보와 토큰을 정리한다.
• 공용 기기 시나리오에서는 뒤로가기, 자동완성, 브라우저 캐시, 다운로드 파일명에 민감 정보가 남지 않는지 확인한다.

• `dangerouslySetInnerHTML`, `innerHTML`, Markdown renderer, rich editor, LLM output renderer를 XSS sink로 본다.
• CSP는 nonce 또는 hash 기반으로 시작하고 `unsafe-inline`, `unsafe-eval`을 줄인다.
• HSTS, X-Frame-Options 또는 frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy를 점검한다.
• 클릭재킹 방어가 필요한 관리자와 결제 화면에는 frame 제한을 명확히 둔다.
• 오류 페이지와 500 응답에 stack trace, 내부 경로, DB 테이블명, 라이브러리 버전을 노출하지 않는다.

• CORS는 브라우저 읽기 정책이고 인증/인가가 아니다. API는 CORS와 별개로 서버 권한 검사를 해야 한다.
• `Access-Control-Allow-Origin: *`와 `Access-Control-Allow-Credentials: true` 조합, origin reflection, 과도한 allow header를 피한다.
• 쿠키 기반 인증의 상태 변경 요청은 CSRF token, signed double-submit cookie, Origin/Referer 검증, Fetch Metadata를 조합한다.
• GET 요청은 상태를 바꾸지 않게 하고, 관리자/결제/비밀번호 변경 요청은 재인증 또는 사용자 상호작용을 추가한다.
• 웹훅과 외부 연동 endpoint는 브라우저 CORS가 아니라 서명 검증, replay 방지, 허용 event type으로 보호한다.

• 개인정보, 결제, 관리자, 인증 후 API 응답은 `Cache-Control: no-store` 또는 서비스 성격에 맞는 private cache 정책을 둔다.
• CDN 캐시는 Authorization, Cookie, tenant, language, query를 캐시 키에 어떻게 반영하는지 확인하고 인증 응답이 public cache에 섞이지 않게 한다.
• Service Worker는 API 응답을 무심코 cache-first로 저장하지 않게 하고, 로그아웃/계정 전환 시 관련 cache를 삭제한다.
• 페이지 뒤로가기와 bfcache로 민감 화면이 복원되는 경우를 테스트하고, 필요하면 no-store와 클라이언트 상태 정리를 병행한다.
• 공개 CDN에 HTML을 캐시할 때 사용자별 콘텐츠, A/B 테스트 쿠키, 관리자 preview가 cache poisoning으로 섞이지 않는지 확인한다.

• 외부 iframe, embed, 광고, 위젯은 가능한 sandbox와 최소 allow 속성을 적용한다.
• postMessage는 `targetOrigin: "*"`를 피하고, 수신 측은 exact origin, message schema, action allowlist를 검증한다.
• YouTube, 지도, 결제, 댓글, 분석 스크립트는 어떤 쿠키와 개인정보를 제3자에게 보내는지 개인정보 처리방침과 일치시킨다.
• iframe 안의 콘텐츠가 부모 창을 이동시키거나 새 탭을 열 수 있는 권한을 필요한 만큼만 준다.
• 관리자와 결제 화면은 frame-ancestors 또는 X-Frame-Options로 원치 않는 embedding을 막는다.

• 파일 크기 제한은 개별 파일과 전체 요청 모두에 둔다.
• 파일명은 서버에서 새로 만들고 원본 파일명은 표시용 메타데이터로만 저장한다.
• 확장자와 MIME type은 allowlist로 검증하고, 이미지라면 가능하면 재인코딩한다.
• MIME만 믿지 말고 magic byte, 실제 디코딩 가능 여부, 이중 확장자, 대소문자 우회, null byte를 점검한다.
• SVG, HTML, JS, 실행 파일은 public bucket에 두지 않는다.
• 업로드 저장소는 실행 권한을 제거하고 앱 서버와 업로드 서빙 도메인을 가능하면 분리한다.
• 이미지 리사이징, PDF 변환, 압축 해제 라이브러리는 sandbox, resource limit, 최신 패치, zip bomb/압축 해제 경로 우회를 확인한다.
• 이미지 EXIF에는 위치, 시간, 기기 정보가 있을 수 있으므로 제거를 검토한다.

• 다운로드 API는 파일 소유권 또는 권한을 서버에서 확인한다.
• `?file=../../.env` 같은 path traversal을 테스트한다.
• public bucket URL을 로그아웃 상태와 다른 사용자 계정으로 열어 본다.
• 삭제 요청 시 원본, 썸네일, 변환 파일, 캐시, 백업의 처리 범위를 문서화한다.
• signed URL은 짧은 만료와 최소 권한으로 발급한다.

• 클라우드 보안은 shared responsibility다. 제공자가 지켜주는 영역과 내가 설정해야 하는 영역을 나눈다.
• AWS, Cloudflare, Supabase, VPS 계정은 MFA와 최소 권한 IAM을 적용한다.
• VPS Postgres 5432, Redis, admin panel을 인터넷에 직접 열지 않는다.
• SSRF 방어를 위해 metadata IP, private IP, localhost, link-local 주소 접근을 차단한다.
• 사용하지 않는 subdomain, DNS record, bucket, preview deployment를 정리해 subdomain takeover를 막는다.
• 서버가 외부 URL을 가져오는 기능은 `http/https` allowlist, redirect 재검증, DNS rebinding 방어, private IP/metadata IP 차단을 적용한다.
• SSRF 방어는 코드 allowlist와 네트워크 egress 제한을 같이 둔다. 코드 검증이 뚫려도 내부망 접근이 막혀야 한다.

• Docker image에는 secret, `.env`, SSH key, 빌드 캐시가 레이어로 남지 않게 한다.
• 컨테이너는 rootless, read-only filesystem, 최소 base image, image scan을 검토한다.
• 백업은 암호화하고 복구 테스트를 한다. 백업이 있다는 말은 복구가 된다는 뜻이 아니다.
• RTO/RPO, 비상 연락망, 키 회전, 점검 순서를 사고 대응 문서에 둔다.
• 도메인 만료일, TLS 인증서 만료일, billing 실패 알림을 모니터링한다.

• 결제 금액, 상품 가격, 할인율, 포인트, 쿠폰, plan은 프런트 값이 아니라 서버 DB 기준으로 다시 계산한다.
• PG/Stripe/국내 결제 웹훅은 서명을 검증하고 idempotency key 또는 event id로 중복 처리를 막는다.
• 웹훅 서명은 raw body 기준으로 검증하고 timestamp tolerance, replay 방지, event type allowlist를 적용한다.
• 결제 성공 페이지, 클라이언트 callback, 프런트 상태값을 paid 근거로 쓰지 말고 provider API와 서버 주문 상태를 대조한다.
• 수량, 가격, 할인율, 포인트는 정수/Decimal, min/max, 통화 단위, 반올림 규칙을 서버에서 검증하고 음수/0/초과값을 테스트한다.
• 환불, 취소, 실패, 부분 결제, 중복 결제, chargeback도 정상 결제만큼 서명 검증과 상태 전이를 점검한다.
• 무료 체험, 쿠폰, 추천 보상, 포인트 적립은 race condition과 반복 요청을 테스트한다.
• AI API, 이미지 생성, 이메일, SMS, 크롤링, 파일 변환에는 사용자별/조직별 quota와 rate limit을 둔다.
• 사용량 폭증 알림과 결제 한도 알림을 provider 대시보드에서 켠다.

• 티켓 구매, 댓글, 가입, 초대 링크, 투표, 다운로드 같은 흐름은 자동화 남용을 가정한다.
• rate limit은 IP만이 아니라 계정, 기기, 세션, 결제수단, 조직 단위도 고려한다.
• 동일 요청 두 번 보내기, 순서 바꾸기, 중간 단계 건너뛰기, 음수/0/큰 값 입력을 테스트한다.
• GraphQL은 depth, complexity, batching, introspection 노출을 점검한다.
• WebSocket은 연결 시 인증뿐 아니라 메시지마다 권한, Origin, token 만료를 고려한다.

• 도메인은 Cloudflare 같은 CDN/WAF 뒤에 두고 원본 서버 IP는 직접 노출되지 않게 한다.
• 원본 방화벽은 CDN IP 대역, private network, tunnel 등 필요한 경로만 허용한다.
• DNS record, 과거 서브도메인, MX/SPF, preview deployment, 로그와 에러 페이지에서 원본 IP가 새는지 확인한다.
• Under Attack Mode, Managed Rules, Bot Fight, rate limiting, challenge rule을 언제 켤지 운영 절차에 적는다.
• 정적 자산은 cache를 활용하고, 동적 API는 인증/인가와 별개로 요청량 제한을 둔다.

• AI API, 이미지 생성, 이메일, SMS, 크롤링, 파일 변환, DB write에는 사용자/조직/일 단위 quota를 둔다.
• AWS Budgets, Google Cloud Budget, OpenAI Usage Limits, Anthropic workspace limit, Cloudflare 알림을 켠다.
• 자동결제와 자동 리로드는 필요한 경우에만 켜고, 개인 프로젝트는 선불 크레딧, 가상카드, 체크카드로 물리적 상한을 만든다.
• 갑작스러운 429, 5xx, 특정 endpoint 호출 급증, AI token 사용량 급증, 트래픽 전송량 급증에 경보를 둔다.
• 무료 체험, 익명 기능, 공개 API는 계정 단위뿐 아니라 IP, device, 세션, 결제수단, user agent 단위 남용을 같이 본다.

• 첫 1시간에는 트래픽 차단, CDN 방어 모드, 원본 firewall, provider 지원 요청, 로그 보존을 동시에 진행한다.
• 한국 운영자는 KISA 118, 호스팅사 보안팀, 경찰청 사이버수사대 신고 경로를 미리 적어둔다.
• 랜섬 DDoS 협박은 결제하지 않고 증거를 보존한다. 결제는 재공격과 추가 협박을 부를 수 있다.
• 공격이 SQLi나 계정 탈취 시도를 가리는 시선 분산일 수 있으므로 로그인 실패, 관리자 접근, DB 오류도 함께 본다.
• 사후에는 공격 시점, 벡터, 트래픽 규모, 비용 영향, 적용한 룰, 누락된 경보를 post-mortem으로 남긴다.

• 자산 목록, 데이터 분류, 신뢰 경계, 외부 연동, 관리자 권한, 규제 요구사항을 적는다.
• 기능 요구사항 옆에 보안 요구사항을 붙인다. 예: “메모 생성” 옆에 “소유자만 읽기/수정/삭제”.
• L1/L2/L3 위험 레벨을 정한다. 개인정보, 결제, 인증 코어, 관리자 기능은 L2 이상으로 본다.

• DFD를 텍스트로라도 작성한다. browser, API, DB, storage, queue, AI provider, admin을 나눈다.
• STRIDE로 spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege를 훑는다.
• 권한 행렬을 만든다. actor, resource, action, condition, expected result를 표로 적는다.

• PR 템플릿에 인증, 인가, 입력 검증, 로그 마스킹, secret, migration, rate limit 체크 항목을 넣는다.
• AI가 만든 코드는 기능 PR과 보안 리뷰 PR을 분리해서 본다.
• 새 패키지와 새 외부 API를 도입하면 공급망과 개인정보 전송 여부를 같이 검토한다.

• SAST, SCA, secret scan, DAST, 수동 악용 테스트를 위험도에 맞춰 적용한다.
• 발견한 취약점은 수정 후 재현 테스트를 회귀 테스트로 고정한다. 같은 실수가 다음 배포에서 되살아나면 안 된다.
• 배포 전 체크리스트와 배포 후 로그 확인 시간을 정한다.
• 분기별로 30분짜리 tabletop 훈련을 해본다. “키 유출”, “관리자 계정 탈취”, “결제 웹훅 위조”, “DDoS 비용 폭탄” 시나리오를 말로라도 끝까지 굴린다.
• 사고 대응 플레이북과 보안 제보 채널, security.txt, 비공개 취약점 처리 절차를 준비한다.

• 로그인 없이 `/api`, `/admin`, `/dashboard`, `/settings`를 직접 열어 본다.
• 다른 사용자 ID, 주문 ID, 메모 ID, 파일 ID로 바꿔 호출해 401, 403, 404가 나오는지 확인한다.
• 브라우저 개발자 도구 Network 응답에 이메일, 토큰, 내부 ID, role, 결제 정보가 과하게 내려오지 않는지 본다.
• `.env`, service key, DB URL, JWT secret, Cloudflare token, Turso token이 Git 히스토리와 배포 로그에 없는지 검색한다.
• 관리자 계정, 이메일 계정, GitHub, Cloudflare, Supabase, VPS 계정에 2FA를 켠다.

• 정말 필요한 정보만 수집한다. 이메일이 필요 없으면 받지 않는다.
• 개인정보처리방침, 수집 항목, 보존 기간, 삭제 방법을 서비스 화면에서 확인 가능하게 둔다.
• 로그에 이메일 전체, 전화번호, Authorization 헤더, reset token, 결제 정보를 남기지 않는다.
• 테스트 DB와 production DB를 분리하고 실제 유저 데이터를 테스트용으로 복사하지 않는다.
• 삭제 요청이 들어오면 DB, 파일, 로그, 백업에서 어디까지 삭제할지 문서화한다.

• AI에게 production 데이터, 유저 이메일 목록, 결제 내역, 실제 API 키를 붙여넣지 않는다.
• AI가 추천한 패키지는 설치 전 실제 존재 여부, 다운로드 수, 관리자 변경, license, postinstall script를 확인한다.
• AI에게 “이 기능을 악용할 방법을 찾아라”, “인증 없이 접근 가능한 엔드포인트를 찾아라”라고 별도 검토를 시킨다.
• 에이전트에게 전체 DB, 전체 파일시스템, 배포 권한을 한 번에 주지 않는다.
• MCP 서버, 자동 배포, 브라우저 자동화는 최소 권한과 승인 단계를 둔다.

• 기능별 데이터 흐름도와 권한 행렬을 만든다. actor, resource, action, condition을 표로 적는다.
• OWASP ASVS를 기준으로 인증, 세션, 접근 통제, 입력 검증, 암호화, 오류 처리, API 요구사항을 체크한다.
• NIST SSDF 방식으로 보안 요구사항, 설계 결정, 위험, 검증 결과를 개발 수명주기에 남긴다.
• CISA Secure by Design 관점으로 기본 보안값, 고객 보안 결과, 투명한 취약점 처리, 리더십 책임을 문서화한다.
• 데이터 분류표를 만든다. 공개 데이터, 내부 데이터, 개인정보, 민감정보, 결제 정보, 비밀키를 분리한다.

• SAST, dependency audit, secret scan, license scan을 CI에 넣고 실패 기준을 정한다.
• DAST 또는 OWASP ZAP으로 공개 경로, API, 인증 우회, 보안 헤더, CORS, XSS, redirect를 점검한다.
• API에는 객체 수준 권한, 속성 수준 권한, 함수 수준 권한, rate limit, pagination limit, body size limit을 둔다.
• DB는 least privilege 계정, migration 계정, app 계정, read-only 계정을 분리한다.
• PostgreSQL RLS를 쓴다면 `ENABLE ROW LEVEL SECURITY`, policy, `FORCE ROW LEVEL SECURITY`, owner bypass, `BYPASSRLS` 역할을 함께 확인한다.

• 관리자 라우트는 일반 사용자 라우트와 다른 미들웨어 체인, 더 짧은 세션, MFA, audit log를 적용한다.
• 관리자 경로 숨김, robots 차단, IP allowlist만으로 보안이 완성된다고 보지 않는다.
• 관리자 mutation에는 CSRF token, Origin/Referer 검증, role 검증, resource ownership 검증, 변경 전후 감사 로그를 둔다.
• super_admin 수를 최소화하고 콘텐츠, 사용자, 시스템, 재무 관리자 역할을 분리한다.
• 대량 사용자 조회, export, 권한 변경, 새 관리자 생성, 비정상 시간대 로그인에 경보를 둔다.

• OAuth/OIDC/SAML은 issuer, audience, redirect URI allowlist, state, nonce, token validation을 명확히 검증한다.
• SSRF 가능 URL 입력은 DNS rebinding, redirect, private IP, metadata IP, IPv6, encoded URL을 테스트한다.
• GraphQL은 introspection, depth, complexity, batching, field-level authorization을 점검한다.
• WebSocket은 연결 시점뿐 아니라 메시지 단위 인증, 인가, Origin, token 만료, rate limit을 점검한다.
• 캐시, 큐, 비동기 작업, 이메일 발송 작업에도 tenant_id와 권한 경계를 유지한다.

• 로그 마스킹, 감사 로그, 관리자 작업 로그, 대량 export 로그, 권한 변경 로그를 분리한다.
• 로그인 실패 급증, 403/404 급증, 429 급증, 비용 스파이크, AI API 사용량 스파이크에 경보를 둔다.
• 백업 암호화, 복구 테스트, RTO/RPO, 키 회전, 비상 연락망, 침해 공지 초안을 준비한다.
• 유출 판단 시 어떤 데이터가 언제부터 얼마나 누구에게 노출됐는지 재구성 가능한 로그를 남긴다.
• 외부 취약점 제보 채널과 보안 이슈 비공개 처리 절차를 마련한다.

• 로그인하지 않고 `/api`, `/admin`, `/dashboard`, `/settings`를 연다.
• 일반 사용자로 관리자 URL에 직접 접근한다.
• 사용자 A로 로그인한 뒤 URL의 userId, memoId, orderId, fileId를 사용자 B의 값으로 바꾼다.
• Authorization 헤더를 제거하고 같은 API를 호출한다.
• 로그아웃 뒤 뒤로가기와 이전 URL 직접 접근을 테스트한다.

• 요청 body에 `role`, `isAdmin`, `plan`, `price`, `balance`, `owner_id`를 추가한다.
• 검색창, 제목, 메모, 댓글에 XSS와 SQL injection 기본 payload를 넣어본다.
• 비밀번호 재설정 링크를 두 번 사용한다.
• 동일 결제/쿠폰/포인트 요청을 빠르게 두 번 보낸다.
• 큰 파일, 확장자를 속인 파일, SVG 파일, `../` 경로가 섞인 다운로드 요청을 테스트한다.

• Network 응답에 화면에서 안 쓰는 민감 필드가 있는지 본다.
• `/.git`, `/debug`, `/health`, `/status`, `/robots.txt`, `/sitemap.xml`, source map을 열어본다.
• 파일 URL을 로그아웃 상태와 다른 계정으로 열어본다.
• 로그에 비밀번호, token, Authorization header, 이메일 전체가 찍히는지 본다.
• AI API와 결제 provider 사용량 알림이 켜져 있는지 확인한다.

이 칼럼은 1인 개발자와 초보자가 빠뜨리기 쉬운 보안 영역을 한 번에 훑는 기준 문서입니다. 인증, 세션, 권한, RLS, 시크릿, CORS/CSRF, SSRF, 파일, 결제, 공급망, LLM, 운영 대응까지 기본선은 잡을 수 있습니다. 다만 실제 서비스의 법률 판단, 침투테스트, 클라우드 계정 포렌식, 고위험 결제/의료/금융 심사는 전문가 검토가 필요합니다.

Top 10은 출발점입니다. 실제 개발에는 ASVS, Cheat Sheet, API Security Top 10, LLM Top 10, 의존성 점검, 시크릿 점검, 로그와 사고 대응까지 같이 봐야 합니다.

anon 또는 publishable key 자체는 클라이언트 사용을 전제로 하지만, 테이블 RLS와 정책이 제대로 있어야 안전합니다. service_role key는 RLS를 우회하므로 브라우저에 절대 들어가면 안 됩니다.

D1은 Workers binding으로 서버 코드에서 접근하는 구조에 맞습니다. 브라우저가 D1에 직접 붙는 구조가 아니라 서버 API에서 인증, 인가, 입력 검증, rate limit을 직접 구현해야 합니다.

토큰이 서버에만 있고 scope가 최소화되어 있으면 출발점은 좋습니다. 그러나 토큰이 브라우저, 저장소, 로그, CI에 노출되면 DB 접근권이 노출됩니다. 조직, 그룹, 읽기 전용 범위로 줄이고 주기적으로 회전해야 합니다.

이메일 하나도 개인정보가 될 수 있습니다. 이 글은 법률 자문이 아니지만, 수집 목적, 안전조치, 처리방침, 유출 통지와 신고, 삭제 요청 처리 범위를 미리 갖추는 것이 안전합니다.

학습용이면 괜찮지만 운영 서비스에서는 위험합니다. 비밀번호 KDF, JWT 저장, OAuth state와 PKCE, refresh token rotation, MFA, 패스키, 계정 열거 방지, 크리덴셜 스터핑 대응까지 모두 운영 책임이 되기 때문입니다. 신규 서비스는 매니지드 인증을 우선 검토하는 편이 안전합니다.

예. 로그인, OTP, MFA, 비밀번호 재설정은 비용보다 계정 탈취가 핵심 위험입니다. 계정, IP, 기기, 세션 단위 제한과 점진적 지연, 임시 잠금, 재전송 cooldown, 위험 기반 CAPTCHA를 따로 설계해야 합니다.

신뢰된 도메인 URL처럼 보이는데 실제로는 공격자 사이트로 보내 피싱 신뢰도를 높입니다. OAuth callback, 로그인 후 이동, 이메일 인증 링크의 next, returnTo, redirect 파라미터는 상대 경로나 서버 allowlist로 제한해야 합니다.

성능 기능이지만 보안 경계이기도 합니다. 인증된 API 응답이 CDN public cache에 섞이거나 Service Worker cache, IndexedDB, bfcache에 민감 화면이 남으면 다른 사용자나 공용 기기에서 노출될 수 있습니다.

서버 전용 보관은 출발점일 뿐입니다. 키 scope, 만료, 회전, 사용량 한도, 예산 알림, 자동결제/자동 리로드 설정, CI/CD OIDC 키리스 인증, 로그 마스킹까지 같이 봐야 합니다. 키 유출은 데이터 유출과 청구서 폭탄을 동시에 만들 수 있습니다.

예. 공격자가 꼭 대기업만 노리는 것은 아닙니다. 봇이나 자동화 공격은 비용이 낮고, 작은 사이트는 오히려 방어가 약합니다. CDN/WAF, 원본 IP 격리, rate limit, bot 방어, 사용량 경보, KISA 118 신고 절차 정도는 개인 프로젝트도 기본선으로 두는 것이 좋습니다.

아닙니다. CORS는 브라우저의 교차 출처 응답 읽기 정책입니다. curl, 서버 요청, 같은 출처 요청, 탈취된 세션 악용을 막는 권한 검사가 아니므로 API는 서버에서 인증과 인가를 반드시 해야 합니다.

JWT 자체가 안전을 보장하지 않습니다. 서명 알고리즘 고정, issuer/audience/expiry 검증, 짧은 만료, refresh token rotation, logout invalidation, 민감정보 payload 금지가 함께 있어야 합니다.

AI는 1차 점검과 코드 흐름 정리에 유용하지만 완전한 보증은 아닙니다. 실제 런타임 설정, TLS, 배포 로그, secret leak, 인프라 권한, race condition, 결제 웹훅은 도구와 수동 테스트가 필요합니다.

부족합니다. 크기 제한, MIME 검증, 서버 생성 파일명, public 접근 권한, SVG/HTML 차단, 이미지 재인코딩, EXIF 제거, 다운로드 권한 검사, path traversal 테스트가 필요합니다.

숨긴 경로는 보조 수단일 뿐입니다. 관리자 인증, MFA, 짧은 세션, CSRF 방어, 관리자 role 검증, audit log, 접근 경보, 가능하면 ZTNA/VPN 같은 다층 방어가 필요합니다.