brain

보안의 지도: CIA · 취약점 · 위협 · OWASP Top 10

상황

“보안 신경 써 줘”라고 AI에게 말했는데, 무엇을 지켜야 하는지 기준이 없으니 결과도 확인할 수가 없다.
보안 기사를 읽으면 취약점·위협·공격·익스플로잇 같은 말이 섞여 나와 같은 말인지 다른 말인지 헷갈린다.
웹 보안 점검을 하려는데 어디서부터 봐야 할지 목록이 없다.

용어

CIA 3요소 — 보안이 지키려는 세 가지. 보안 사고는 이 중 무엇이 깨졌나로 설명할 수 있다.
- Confidentiality(기밀성) — 볼 권한이 있는 사람만 볼 수 있어야 한다. 깨지면: 개인정보 유출, 남의 주문 내역 열람.
- Integrity(무결성) — 허락받은 사람만, 허락된 방식으로만 바뀌어야 한다. 깨지면: 남의 글 수정, 결제 금액 조작.
- Availability(가용성) — 필요할 때 쓸 수 있어야 한다. 깨지면: DDoS(Distributed Denial of Service)로 서비스 마비(인프라 용어 14번), 랜섬웨어로 데이터 잠김.
- 비유: 은행 금고. 아무나 못 들여다보고(기밀성), 몰래 금액을 못 바꾸고(무결성), 고객이 찾을 때 열 수 있어야(가용성) 한다.
자주 섞이는 네 단어
- vulnerability(취약점) — 시스템의 약한 곳. “주문 API가 주인 확인을 안 한다.”
- threat(위협) — 그 약점을 노릴 수 있는 존재·상황. “다른 사용자, 자동화된 봇.”
- attack / exploit(공격 / 익스플로잇) — 약점을 실제로 이용하는 행위·방법(코드). “주소의 id를 1씩 바꿔 가며 다 긁어 가기.”
- risk(위험) — 피해가 날 가능성 × 피해 크기. 우선순위는 위험으로 정한다(기획 용어 8번 severity와 비슷한 발상).
- 비유: 집 창문 잠금장치 고장(취약점), 동네 빈집털이범(위협), 그 창문으로 실제 침입(공격), “1층이라 털리기 쉽고 귀중품이 많다”(위험).
attack surface(공격 표면) — 바깥에서 건드릴 수 있는 모든 지점(인프라 용어 11번). 입력 칸, API 주소, 파일 업로드, 열린 포트, 설치한 라이브러리까지.
OWASP Top 10 — 보안 비영리 단체 OWASP(Open Worldwide Application Security Project)가 데이터로 정리한 웹 애플리케이션의 가장 흔하고 위험한 취약점 10가지 분류. 몇 년마다 새 판이 나오며 순서·구성이 조금씩 바뀌므로 점검할 땐 최신판을 확인한다. 꾸준히 상위에 오르는 범주:
- broken access control(접근 제어 실패) — 남의 데이터·관리자 기능에 접근됨(다음 레슨, IDOR 포함)
- injection(주입) — 입력이 명령으로 해석됨(웹 용어 25번 SQL injection, XSS 포함)
- cryptographic failures(암호화 실패) — 민감 정보를 평문으로 저장·전송(인프라 용어 3번 HTTPS)
- authentication failures(인증 실패) — 약한 비밀번호 저장, brute force 무방비(웹 용어 23번, 인프라 용어 14번)
- security misconfiguration(보안 설정 오류) — 기본 설정 그대로, 디버그 모드, 열린 버킷
- vulnerable components / supply chain(취약한 구성 요소·공급망) — 오래되거나 오염된 라이브러리(진단 Q3)
- insecure design(안전하지 않은 설계), logging & monitoring failures(기록·감시 실패), SSRF(Server-Side Request Forgery) 등
- 이 목록은 AI에게 보안 점검을 시킬 때 체크리스트로 쓰기 좋다(상황 1·3 해결).

지시 예문

“이 앱을 최신 OWASP Top 10 범주별로 점검해줘. 범주마다 해당 위험이 있는 코드 위치, 근거, 수정 우선순위를 표로.”
“이번 보안 이슈를 CIA 중 무엇이 깨진 건지, 취약점·위협·공격·위험으로 나눠서 설명해줘.”
“우리 서비스의 attack surface 목록을 만들어줘. 공개 API, 입력 폼, 파일 업로드, 외부 연동, 설치된 패키지까지.”

접근 제어 실패: IDOR · 권한 상승 · 서버 측 검사 · mass assignment

사용자마다 서버에서 자원 소유권을 확인 — 서버가 요청자와 자원의 소유 관계를 확인해 다른 사람의 주문 접근을 막는 예입니다.

상황

주문 주소 /orders/1024의 숫자를 1025로 바꾸니 남의 주문 내역이 보인다(진단 Q2).
관리자 메뉴 버튼을 일반 회원 화면에서 숨겼는데, 누군가 주소창에 /admin을 직접 쳐서 들어왔다.
회원정보 수정 요청에 "role": "admin"을 몰래 끼워 보냈더니 관리자가 됐다.

용어

access control(접근 제어) — “누가 무엇을 할 수 있는가“를 강제하는 장치. 웹 용어 23번 인가(authorization)를 실제로 지키는 것. OWASP(Open Worldwide Application Security Project) Top 10에서 오랫동안 가장 흔한 취약점 범주.
IDOR(Insecure Direct Object Reference, 안전하지 않은 직접 객체 참조) — 요청에 들어 있는 id만 바꿔서 남의 데이터에 접근되는 구멍(상황 1, DB 용어 15번). 서버가 “이 주문이 요청한 사람의 것인가”를 확인하지 않아서 생긴다.
- UUID(Universally Unique Identifier)로 바꾸면 추측은 어려워지지만 근본 해결이 아니다. 링크가 한 번 새면 끝. 핵심은 매 요청마다 소유자 확인(DB 용어 12번 RLS(Row Level Security)).
privilege escalation(권한 상승) — 원래보다 더 큰 권한을 얻는 것.
- horizontal(수평) — 같은 등급의 다른 사람 권한을 얻음. 남의 주문 보기(IDOR).
- vertical(수직) — 더 높은 등급의 권한을 얻음. 일반 회원이 관리자 기능 사용(상황 2·3).
- 비유: 아파트. 수평은 옆집 문을 여는 것, 수직은 관리사무소 마스터키를 손에 넣는 것.
client-side vs server-side check(화면 쪽 검사 vs 서버 쪽 검사) — 버튼 숨기기, 화면에서 입력 막기는 편의일 뿐 보안이 아니다. 사용자는 브라우저 개발자 도구(웹 용어 36번)나 직접 만든 요청으로 화면을 건너뛸 수 있다(상황 2). 권한 검사는 반드시 서버(API·DB)에서 한다.
- 비유: 공연장 입구에 “관계자 외 출입 금지” 팻말(화면 숨김)만 세워 두는 것 vs 문에 경비원(서버 검사)을 세우는 것.
- forced browsing(강제 탐색) — 링크가 없어도 /admin, /api/users 같은 주소를 직접 쳐서 들어가 보는 것. 숨긴 주소는 숨겨진 게 아니다.
deny by default(기본 거부) — 명시적으로 허락한 것 외에는 전부 막는 원칙. 새 API를 만들면 기본이 “아무도 못 씀”이고, 필요한 권한만 열어 준다. DB 용어 12번 “RLS 켜고 정책 없으면 전부 거부”가 이 원칙.
mass assignment(일괄 할당) — 요청에 들어온 값을 통째로 DB에 저장하다가, 사용자가 바꾸면 안 되는 필드(role, is_admin, balance, user_id)까지 덮어쓰는 취약점(상황 3).
- 대책: 받을 필드를 허용 목록(allowlist)으로 명시한다. “이름·닉네임·프로필 사진만 받는다”. 나머지는 무시.
- AI가 만든 “update 요청 body를 그대로 DB에 저장” 코드에서 자주 생긴다.

지시 예문

“모든 API를 훑어서, id를 받아 데이터를 조회·수정·삭제하는 곳마다 ‘요청한 사용자 소유인지’ 서버에서 확인하는지 점검해줘. 빠진 곳은 IDOR로 표시하고 고쳐줘.”
“관리자 기능이 화면에서만 숨겨져 있어. 서버 API와 미들웨어에서 역할(role)을 검사하게 하고, 기본은 거부(deny by default)로 바꿔줘.”
“프로필 수정 API가 요청 body를 통째로 저장하고 있어. mass assignment 막게 name, nickname, avatar만 받는 allowlist로 바꿔줘.”
“일반 회원 계정으로 관리자 API를 직접 호출하는 테스트를 만들어서 403이 나오는지 확인해줘.”

인증 구멍: 해시 · salt · user enumeration · 비밀번호 재설정 · 세션 관리

상황

DB가 유출됐는데 비밀번호가 그대로 읽히는 글자로 저장돼 있었다. 사용자들이 다른 사이트에도 같은 비밀번호를 써서 피해가 번졌다.
로그인 화면이 “존재하지 않는 이메일입니다“와 “비밀번호가 틀렸습니다“를 구분해서 알려준다. 누군가 이걸로 우리 회원 이메일 목록을 알아냈다.
비밀번호 재설정 링크가 몇 달이 지나도 작동하고, 한 번 쓴 링크로 또 바꿀 수 있다.
사용자가 로그아웃했는데, 예전에 복사해 둔 토큰으로 요청하면 여전히 로그인 상태로 처리된다.

용어

authentication(인증) — “누구냐“를 확인하는 것(웹 용어 23번). 1번 레슨 OWASP(Open Worldwide Application Security Project) Top 10의 “인증 실패” 범주.
암호화(encryption) vs 해시(hash) — 둘 다 원래 글자를 알아볼 수 없게 바꾸지만 다르다.
- encryption(암호화) — 열쇠가 있으면 되돌릴 수 있다(복호화). 카드번호처럼 나중에 원본이 필요한 데이터에.
- hash(해시) — 되돌릴 수 없는 한 방향 변환. 같은 입력은 항상 같은 결과. 비밀번호는 해시로 저장하고, 로그인 때 입력값을 같은 방식으로 해시해서 비교만 한다. 원본 비밀번호는 서버도 모른다.
- 비유: 암호화는 자물쇠 상자(열쇠로 다시 연다), 해시는 믹서기(사과 주스를 다시 사과로 못 되돌린다).
- plaintext(평문) 저장 금지 — 상황 1. 절대 원본 그대로 저장하지 않는다.
salt(솔트) — 비밀번호마다 붙이는 무작위 값. 같은 비밀번호라도 사람마다 해시 결과가 달라져, 미리 계산해 둔 해시 목록(rainbow table)으로 한꺼번에 푸는 공격을 막는다.
slow hash(느린 해시) — 비밀번호용으론 일부러 느리게 설계된 해시를 쓴다: bcrypt, scrypt, Argon2. 빠른 해시(MD5(Message Digest 5), SHA-256(Secure Hash Algorithm 256-bit))는 공격자가 초당 수십억 번 대입할 수 있어 비밀번호 저장에 부적합하다. 직접 구현하지 말고 검증된 라이브러리나 인증 서비스(Supabase Auth 등)에 맡긴다.
credential stuffing(크리덴셜 스터핑) — 다른 사이트에서 유출된 아이디·비밀번호를 그대로 대입하는 공격(인프라 용어 14번). 상황 1의 피해가 번지는 이유. 대책: rate limit, MFA(Multi-Factor Authentication, 다단계 인증), 유출 비밀번호 목록과 대조.
user enumeration(사용자 열거) — 응답 차이로 어떤 계정이 존재하는지 알아내는 것(상황 2). 로그인·회원가입·비밀번호 찾기에서 같은 문구로 답한다: “이메일 또는 비밀번호가 맞지 않아요”, “가입된 이메일이라면 재설정 링크를 보냈어요”.
- UI 용어 17번 “좋은 에러 메시지는 구체적으로”와 충돌하는 지점 — 인증 화면만큼은 보안이 우선이라 일부러 모호하게 쓴다.
비밀번호 재설정 흐름 — 재설정 링크(토큰)는 짧은 유효기간(예: 30분~1시간), 한 번만 사용, 사용·변경 후 즉시 폐기, 추측 불가능한 긴 무작위 값(상황 3). 비밀번호를 바꾸면 다른 기기의 세션도 끊는 선택지를 준다.
session management(세션 관리) — 로그인 상태를 안전하게 다루는 것(웹 용어 23번 세션·토큰).
- 로그아웃 = 서버에서 무효화 — 브라우저 쿠키만 지우면 복사해 둔 토큰은 계속 쓸 수 있다(상황 4). 세션은 서버에서 지우고, 토큰은 짧은 만료 + 폐기 목록(revocation)으로 관리한다.
- session fixation(세션 고정) — 공격자가 미리 정해 둔 세션 ID로 피해자를 로그인시키는 공격. 로그인 성공 시 세션 ID를 새로 발급해 막는다.
- 쿠키 설정: httpOnly(JS(JavaScript)가 못 읽음), Secure(HTTPS로만), SameSite(다른 사이트 요청엔 안 보냄, 웹 용어 25번 CSRF(Cross-Site Request Forgery) 대비).

지시 예문

“비밀번호가 어떻게 저장되는지 확인해줘. 평문이나 빠른 해시(MD5·SHA-256)면 bcrypt나 Argon2로 바꾸는 마이그레이션 계획을 세워줘. 기존 사용자는 다음 로그인 때 다시 해시하는 방식으로.”
“로그인·회원가입·비밀번호 찾기 응답에서 계정 존재 여부가 드러나는 user enumeration이 있는지 점검하고, 문구와 응답 시간을 동일하게 맞춰줘.”
“비밀번호 재설정 토큰을 30분 만료, 1회용, 사용 즉시 폐기로 바꾸고, 비밀번호 변경 시 다른 기기 세션을 모두 끊는 옵션을 추가해줘.”
“로그아웃 시 서버에서 세션·리프레시 토큰을 무효화하는지 확인하고, 인증 쿠키에 httpOnly·Secure·SameSite가 설정됐는지 점검해줘.”

주입 공격 확장: command injection · path traversal · eval · 입력 검증 원칙

상황

이미지 변환 기능이 사용자가 올린 파일 이름을 그대로 터미널 명령에 넣어 실행한다. 파일 이름을 a.jpg; rm -rf /로 올리자 서버 파일이 지워졌다.
파일 다운로드 주소가 /download?file=report.pdf인데, file=../../.env로 바꾸자 서버의 비밀 설정 파일이 내려받아졌다.
계산기 기능을 빨리 만들려고 사용자가 입력한 수식을 eval()로 실행했더니, 수식 대신 코드를 넣는 사람이 생겼다.

용어

injection(주입) — 사용자 입력이 데이터가 아니라 명령으로 해석되는 모든 공격의 총칭(웹 용어 25번에서 SQL injection·XSS(Cross-Site Scripting)로 배움). 공통 원인은 하나: 입력과 명령을 섞었다.
- 비유: 식당 주문서에 “짜장면 1, 그리고 금고 열어서 돈 다 주세요“라고 적었더니, 주방이 주문서에 적힌 대로 전부 실행해 버린 것. 주문서는 메뉴 칸에 적힌 것만 읽어야 한다.
command injection(명령어 주입) — 입력이 운영체제 명령(셸)의 일부로 실행되는 것(상황 1). 서버 전체를 장악당할 수 있어 가장 위험한 축.
- 대책: 사용자 입력을 셸 문자열에 이어 붙이지 않는다. 명령 실행이 꼭 필요하면 인자를 목록(배열)으로 따로 넘기는 방식(셸을 거치지 않는 실행)을 쓰고, 가능하면 라이브러리 함수로 대신한다(이미지 변환이면 이미지 라이브러리).
path traversal(경로 조작, 디렉터리 탐색) — 파일 경로에 ../를 넣어 허락된 폴더 밖의 파일에 접근하는 것(상황 2). .env(웹 용어 17번), 설정 파일, 다른 사용자 파일이 노출된다.
- 대책: 사용자가 파일 경로를 직접 정하지 못하게 한다. 파일은 id로 요청받고, 서버가 id → 실제 경로를 찾는다(2번 레슨 IDOR(Insecure Direct Object Reference) 검사와 함께). 꼭 이름을 받아야 하면 허용 폴더 안인지 정규화 후 확인한다. 업로드 파일은 object storage(인프라 용어 5번)에 두면 서버 파일 시스템과 아예 분리된다.
eval / code injection(코드 주입) — 입력을 eval(), new Function()처럼 코드로 실행하는 것(상황 3). 사용자가 서버(또는 다른 사용자 브라우저)에서 아무 코드나 돌릴 수 있게 된다. 사용자 입력을 코드로 실행하는 설계 자체를 피한다 — 계산기라면 수식 전용 파서 라이브러리를 쓴다.
NoSQL injection — SQL이 아닌 DB(DB 용어 19번 document DB 등)에서도, 입력으로 조건 객체({"$ne": null} 같은)를 끼워 넣어 필터를 무력화할 수 있다. “SQL 안 쓰니 안전”은 착각.
입력 처리 3원칙 — 거의 모든 주입을 막는 공통 처방.
1. validation(입력 검증) — 들어오는 값이 예상한 형태인지 확인. allowlist(허용 목록) 방식: “숫자만”, “이 확장자만(.jpg·.png)”, “이 값들 중 하나”. “위험한 것만 막는” denylist(차단 목록)는 빈틈이 생긴다. 검증은 서버에서(2번 레슨).
2. parameterization / separation(명령과 데이터 분리) — 입력을 명령 문장에 이어 붙이지 않고 칸을 나눠 넘긴다(웹 용어 25번 parameterized query, 위 command 배열 인자).
3. output encoding(출력 인코딩) — 화면·HTML·URL에 넣을 때 그 자리에 맞게 특수문자를 안전하게 바꿔 넣는다(XSS 대책, 다음 레슨).

코드로 보는 예시(❌ 위험 / ⭕ 안전, Node.js 기준)

command injection

// ❌ 셸 문자열에 입력을 이어 붙임 — file = "a.jpg; rm -rf /" 이면 두 번째 명령까지 실행
exec(`convert ${file} out.png`)
// ⭕ 셸을 거치지 않고 인자를 배열로 — file은 통째로 "파일 이름 하나"로만 취급
execFile('convert', [file, 'out.png'])
// ⭕⭕ 명령 대신 라이브러리
await sharp(file).toFile('out.png')

path traversal

// ❌ path.join('/app/uploads', '../../.env') → '/.env' (업로드 폴더 밖)
res.sendFile(path.join('/app/uploads', req.query.file))
// ⭕ id로 받고, 소유자 확인 후 서버가 경로를 찾음
const doc = await db.files.findFirst({ where: { id: req.params.id, ownerId: user.id } })
if (!doc) return res.status(404).end()
res.sendFile(doc.storagePath)
// ⭕ 이름을 꼭 받아야 하면: 정규화 후 허용 폴더 안인지 확인
const full = path.resolve(BASE, name)
if (!full.startsWith(BASE + path.sep)) return res.status(403).end()

code injection

// ❌ expr = "process.exit()" 같은 코드도 그대로 실행
eval(req.body.expr)
// ⭕ 수식만 해석하는 전용 파서
import { evaluate } from 'mathjs'
evaluate('2 * (3 + 4)')

NoSQL injection

// ❌ body가 {"email":"admin@x.com","password":{"$ne":null}} 이면
//    "비밀번호가 null이 아닌" 조건이 되어 비밀번호 없이 통과
users.findOne({ email: req.body.email, password: req.body.password })
// ⭕ 타입부터 검증 — 문자열이 아니면 거부 (그리고 비밀번호는 3번 레슨처럼 해시 비교)
const { email, password } = z.object({ email: z.string().email(), password: z.string() }).parse(req.body)

allowlist vs denylist

// ❌ denylist — "<SCRIPT>", "<img onerror=...>" 같은 변형은 그대로 통과
if (name.includes('<script>')) throw new Error('blocked')
// ⭕ allowlist — 허용한 모양만 통과
z.enum(['jpg', 'png']).parse(ext)
z.string().regex(/^[a-zA-Z0-9_-]{1,30}$/).parse(username)

실제 사례
- SQL injection → 여기어때(2017) — 마케팅센터 웹페이지의 SQL injection으로 DB에 저장된 관리자 세션값을 빼냈고, 그 세션으로 외부에 열려 있던 관리 페이지에 관리자로 접속해 회원·예약 정보 약 99만 건이 유출됐다. 원인으로 비정상 DB 질의 검증 부재와 세션 변조 탐지 체계 부재가 지적됐다. 주입 하나가 접근 제어 실패(2번 레슨)·세션 관리 실패(3번 레슨)와 이어져 피해가 커진 사례.
- SQL injection → MOVEit Transfer(2023, CVE-2023-34362) — 파일 전송 솔루션의 SQL injection 제로데이를 랜섬웨어 조직 Cl0p가 악용. 집계에 따라 피해 기관 2,600곳 이상, 개인 7,700만 명 이상. 우리가 쓰는 외부 소프트웨어의 취약점이 우리 데이터를 무너뜨린 사례(다음 레슨들의 의존성·공급망과 연결).
- path traversal → Fortinet SSL VPN(CVE-2018-13379) — VPN 웹 포털의 경로 조작으로 로그인 정보가 담긴 시스템 파일을 인증 없이 내려받을 수 있었다. 패치가 나온 뒤에도 업데이트하지 않은 장비가 많아, 2021년 약 8만 7천 대 장비의 VPN 계정 정보가 공개됐다. 패치 후에도 비밀번호를 바꾸지 않으면 여전히 위험하다는 교훈(인프라 용어 11번 키 유출 후 폐기·재발급).
- code injection → Equifax(2017), Log4Shell(2021) — 미국 신용평가사 Equifax는 웹 프레임워크 Apache Struts의 취약점(요청 헤더 값이 코드처럼 해석됨)으로 약 1억 4,700만 명의 정보가 유출됐다. Log4Shell은 자바 로깅 라이브러리 Log4j가 로그에 남긴 문자열 속 특수 구문을 해석해 외부 코드를 불러오던 문제로, 사용자가 입력한 아이디·검색어가 로그에 찍히기만 해도 서버가 장악될 수 있었다. “로그에 쓰는 값까지 사용자 입력”이라는 원칙의 대표 사례.
never trust user input(사용자 입력을 믿지 마라) — 폼 입력뿐 아니라 URL, 쿠키, 헤더, 업로드 파일 이름, 외부 API 응답, AI 출력까지 전부 “사용자 입력”으로 취급한다. 마지막 항목은 AI 보안 주제의 출발점.

지시 예문

“코드 전체에서 사용자 입력이 셸 명령(exec, spawn with shell), eval, new Function, 파일 경로에 들어가는 곳을 찾아서 command injection·code injection·path traversal 위험을 표시해줘.”
“파일 다운로드를 파일명 대신 파일 id로 받게 바꾸고, 요청자 소유인지 확인한 뒤 서버가 경로를 찾게 해줘.”
“모든 API 입력에 스키마 검증(zod 등)을 붙여줘. allowlist 방식으로 타입·길이·허용값을 정하고, 검증은 서버에서.”
“이 계산기 기능의 eval을 없애고 수식 전용 파서 라이브러리로 바꿔줘.”

XSS 심화와 보안 헤더: stored · reflected · DOM XSS · CSP · clickjacking

상황

React는 XSS(Cross-Site Scripting)를 막아 준다고 들었는데, 프로필의 “내 웹사이트” 링크에 javascript:로 시작하는 주소를 넣으니 클릭한 사람 브라우저에서 스크립트가 실행됐다.
검색 결과 페이지가 “‘검색어’에 대한 결과“를 그대로 화면에 찍는데, 누군가 스크립트가 든 검색 링크를 만들어 메신저로 뿌렸다.
우리 사이트를 다른 사이트가 투명한 액자(iframe)에 넣고, 그 위에 “경품 받기” 버튼을 겹쳐 놓아 사용자가 모르고 우리 사이트의 “계정 삭제“를 눌렀다.

용어

XSS의 세 갈래 — 공통점은 “공격자 스크립트가 다른 사용자 브라우저에서 실행”(진단 Q1). 스크립트가 어디를 거쳐 오는지가 다르다.
- stored XSS(저장형) — 댓글·게시글·프로필처럼 DB에 저장됐다가, 보는 사람마다 실행. 한 번 심으면 계속 퍼져서 가장 위험.
- reflected XSS(반사형) — URL·검색어 같은 요청 값을 그대로 응답 화면에 되비추는 곳에서 발생(상황 2). 공격자가 조작된 링크를 클릭하게 만들어야 한다(피싱과 결합).
- DOM-based XSS(DOM 기반) — 서버를 거치지 않고, 브라우저의 JS(JavaScript)가 URL 조각·입력값을 innerHTML 같은 곳에 넣다가 발생.
output encoding(출력 인코딩) — 넣는 자리에 맞게 — 4번 레슨 3원칙의 세 번째. 같은 입력도 어디에 넣느냐(HTML 본문, HTML 속성, URL, JS 코드 안)에 따라 위험한 문자가 다르다.
- React·Vue 등은 {comment}처럼 텍스트로 넣을 땐 자동으로 안전하게 바꿔 준다. 그러나 다음은 보호 밖이다:
  - dangerouslySetInnerHTML, v-html, innerHTML — HTML을 직접 넣는 곳(웹 용어 25번, DOMPurify로 sanitize).
  - href·src에 사용자 URL — javascript: 같은 위험한 프로토콜이 들어갈 수 있다(상황 1). https://·http://만 허용(allowlist)한다.
security headers(보안 헤더) — 서버 응답에 붙여 브라우저에게 “이 페이지는 이렇게 보호해“라고 지시하는 설정. 코드 실수가 있어도 한 겹 더 막는 defense in depth(다층 방어).
- CSP(Content Security Policy, 콘텐츠 보안 정책) — “이 페이지는 허락한 출처의 스크립트만 실행해”라는 규칙. 공격자가 스크립트를 심어도 출처가 허락 목록에 없으면 브라우저가 실행을 거부한다. XSS의 강력한 2차 방어선. 처음엔 report-only(보고만 하는 모드)로 켜서 깨지는 곳을 확인한 뒤 강제한다.
- clickjacking(클릭재킹) — 우리 페이지를 투명한 iframe에 넣고 다른 버튼을 겹쳐 엉뚱한 클릭을 유도하는 공격(상황 3). CSP의 frame-ancestors 'none'(또는 옛 헤더 X-Frame-Options: DENY)로 다른 사이트가 우리를 액자에 못 넣게 막는다.
- HSTS(HTTP Strict Transport Security) — “앞으로 HTTPS로만 접속해”(인프라 용어 3번).
- X-Content-Type-Options: nosniff — 브라우저가 파일 종류를 멋대로 추측하지 못하게(이미지인 척 올린 스크립트 실행 방지, 다음 레슨들의 파일 업로드와 연결).
- Referrer-Policy — 다른 사이트로 이동할 때 주소(쿼리의 토큰 등)가 새지 않게.
- 비유: 건물 보안. 코드 검증이 입구 검색대라면, 보안 헤더는 방마다 걸린 출입 규칙 안내판을 경비원(브라우저)이 지키게 하는 것. 검색대를 빠져나와도 규칙이 한 번 더 막는다.

지시 예문

“사용자 입력이 dangerouslySetInnerHTML, innerHTML, href, src에 들어가는 곳을 모두 찾아줘. HTML은 DOMPurify로 sanitize하고, URL은 https/http만 허용하게 바꿔줘.”
“검색어를 화면에 그대로 출력하는 곳이 reflected XSS에 안전한지 확인해줘.”
“보안 헤더를 설정해줘: CSP(먼저 report-only로), frame-ancestors ‘none’, HSTS, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin. 적용 후 securityheaders 같은 도구 기준으로 점검 결과도 알려줘.”

SSRF: 서버를 대신 심부름 보내는 공격

상황

링크를 붙이면 제목·썸네일을 가져와 보여주는 링크 미리보기 기능(웹 용어 21번 Open Graph)을 만들었다. 누군가 http://localhost:6379 같은 내부 주소를 넣자, 서버가 바깥에선 접근할 수 없는 내부 서비스에 대신 접속해 응답을 보여줬다.
“이미지 URL로 프로필 사진 등록” 기능에 클라우드의 내부 관리용 주소를 넣자, 서버의 클라우드 접속 키가 담긴 응답이 돌아왔다.
허용한 외부 사이트 주소로 요청했는데, 그 사이트가 내부 주소로 리다이렉트시켜 결국 내부로 들어갔다.

용어

SSRF(Server-Side Request Forgery, 서버 측 요청 위조) — 공격자가 서버에게 원하는 주소로 요청을 보내게 만드는 공격. 서버는 보통 내부망 안쪽에 있어서, 바깥 사용자는 닿을 수 없는 곳(내부 DB·관리 페이지·클라우드 내부 주소)에 서버의 권한으로 접근할 수 있게 된다.
- 웹 용어 25번 CSRF(Cross-Site Request Forgery)는 사용자의 브라우저를 시켜 요청을 보내게 하는 것, SSRF는 우리 서버를 시키는 것.
- 비유: 회사 내부 심부름 직원에게 외부인이 쪽지를 건넨다. “3층 금고실에서 서류 좀 가져다줘요.” 직원은 사원증이 있으니 금고실 문이 열린다. 외부인은 건물에 못 들어가도, 직원을 통해 금고 안을 본다.
어디서 생기나 — 서버가 사용자가 준 URL로 요청을 보내는 모든 기능: 링크 미리보기, URL로 이미지·파일 가져오기, 웹훅(webhook) 주소 등록, PDF(Portable Document Format) 변환기에 웹페이지 주소 넣기, 그리고 AI 에이전트의 “이 URL 읽어 줘” 도구(AI 보안 주제와 직결).
cloud metadata endpoint(클라우드 메타데이터 주소) — 클라우드 서버 안에서만 접근되는 특수 내부 주소(대표적으로 169.254.169.254). 서버 설정과 임시 접속 키를 알려준다. SSRF가 노리는 1순위 표적(상황 2). AWS는 이 주소에 토큰을 먼저 받아야 접근되는 IMDSv2(Instance Metadata Service version 2) 방식을 쓰도록 권장한다.
- 실제 사례 — Capital One(2019): 설정이 잘못된 웹 방화벽을 통해 SSRF로 클라우드 메타데이터에 접근, 접속 키를 얻어 저장소에서 약 1억 명 규모의 고객 정보를 빼낸 사건으로 널리 알려졌다. 인프라 용어 11번 최소 권한이 지켜졌다면 그 키로 할 수 있는 일이 훨씬 적었을 것.
방어
- allowlist(허용 목록) — 요청을 보낼 수 있는 도메인을 정해 둔다. 가능하면 이게 최선.
- 사설·내부 IP 차단 — 임의 URL을 받아야 한다면, 주소를 실제 IP로 풀어 본 뒤(인프라 용어 2번 DNS) 127.0.0.1(localhost), 10.x, 192.168.x, 169.254.x 같은 내부 대역이면 거부한다(인프라 용어 1번 사설 IP).
- 리다이렉트 재검사 — 리다이렉트를 따라가지 않거나, 따라갈 때마다 다시 검사한다(상황 3). 도메인 이름은 겉으로 멀쩡해도 DNS가 내부 IP를 가리키도록 바꾸는 수법(DNS rebinding)도 있어서, 실제 접속하는 IP를 기준으로 확인한다.
- 네트워크로 막기 — URL을 가져오는 일을 내부망과 분리된 별도 서버(또는 함수)에서 하고, 그 서버는 내부로 나가는 길을 막는다(인프라 용어 11번 방화벽). 코드 실수가 있어도 2차로 막힌다(5번 레슨 다층 방어).
- 응답 그대로 돌려주지 않기 — 가져온 응답 전체를 사용자에게 보여주지 말고 필요한 것(제목·썸네일)만 추린다.

지시 예문

“서버가 사용자 입력 URL로 요청을 보내는 곳(링크 미리보기, 이미지 URL 업로드, 웹훅, PDF 변환)을 전부 찾아서 SSRF 위험을 점검해줘.”
“링크 미리보기 요청에 SSRF 방어를 넣어줘: DNS를 풀어 실제 IP를 확인하고 사설·루프백·169.254 대역 차단, 리다이렉트는 매번 재검사, 응답은 제목과 이미지 URL만 추려서.”
“AWS 서버들이 IMDSv2만 쓰도록 설정됐는지 확인하고, 서버 역할(IAM(Identity and Access Management) role) 권한이 최소한인지 점검해줘.”

의존성과 공급망: CVE · CVSS · npm audit · lockfile · supply chain attack

상황

npm install 후 “12 vulnerabilities (3 high)” 경고와 함께 CVE-2025-XXXXX 같은 번호가 떴다(진단 Q3). 무엇을 의미하는지, 무엇부터 고쳐야 하는지 모르겠다.
우리가 직접 설치한 패키지는 20개뿐인데, node_modules 안엔 1,000개가 넘는 패키지가 들어 있다. 그중 하나에 취약점이 있다.
유명한 패키지를 업데이트했을 뿐인데, 그 새 버전에 악성 코드가 들어 있었다.
AI가 추천한 패키지 이름을 그대로 설치했는데, 이름이 비슷한 가짜 패키지였다.

용어

dependency(의존성) — 우리 코드가 가져다 쓰는 외부 라이브러리(기획 용어 7번 dependency와 같은 말, 코드 버전). 현대 웹앱 코드의 대부분은 우리가 쓴 게 아니라 남이 쓴 코드다.
- direct dependency(직접 의존성) — package.json에 우리가 적은 것.
- transitive dependency(간접 의존성) — 그 패키지가 또 가져다 쓰는 패키지들(상황 2). 대부분의 취약점은 여기서 나온다.
CVE(Common Vulnerabilities and Exposures, 공통 취약점 식별자) — 공개된 취약점마다 붙는 고유 번호(CVE-연도-번호). 전 세계가 같은 취약점을 같은 이름으로 부르게 해 준다(진단 Q3의 답). 4번 레슨 사례의 MOVEit(CVE-2023-34362), Fortinet(CVE-2018-13379)도 이 번호.
- 비유: 자동차 리콜 번호. “○○ 차종 브레이크 결함, 리콜 번호 2025-123”처럼, 어느 부품에 어떤 문제가 있는지 공식 이름표를 붙인 것.
CVSS(Common Vulnerability Scoring System, 공통 취약점 점수) — 취약점 심각도를 0~10점으로 매긴 점수. 대략 Low < Medium < High < Critical(9.0 이상). Fortinet 사례는 9.8. 우선순위의 출발점이지만, 우리 코드가 그 취약한 기능을 실제로 쓰는지(도달 가능성)를 함께 봐야 진짜 위험이 나온다(1번 레슨 risk).
npm audit / 취약점 스캐너 — 설치된 패키지를 알려진 CVE 목록과 대조해 알려주는 도구. 진단 Q3의 경고가 이것. npm audit fix로 호환되는 범위 안의 수정 버전으로 올린다. 큰 버전 변경(기획 용어 9번 SemVer(Semantic Versioning)의 MAJOR)은 동작이 깨질 수 있어 테스트(기획 용어 8번 regression test)와 함께.
- Dependabot / Renovate — 취약점이 발견되거나 새 버전이 나오면 업데이트 PR(Pull Request)을 자동으로 만들어 주는 도구.
lockfile(잠금 파일) — package-lock.json, pnpm-lock.yaml처럼 설치된 정확한 버전(간접 의존성까지)을 기록한 파일. 이게 있어야 모든 환경이 똑같은 코드를 설치한다. git에 반드시 커밋하고, 배포·CI(Continuous Integration)에선 lockfile 그대로 설치(npm ci)한다.
supply chain attack(공급망 공격) — 우리를 직접 공격하는 대신 우리가 믿고 쓰는 부품(패키지·도구·업데이트)에 악성 코드를 심어 한꺼번에 퍼뜨리는 공격(상황 3).
- 실제 사례 — npm chalk·debug 사건(2025년 9월): 유명 오픈소스 관리자가 npm을 사칭한 피싱 메일(“2FA(Two-Factor Authentication) 갱신하세요”)에 속아 계정을 빼앗겼고, 공격자가 chalk·debug 같은 매우 널리 쓰이는 패키지에 암호화폐 탈취 코드를 넣어 새 버전으로 배포했다. 두 시간 안팎 만에 내려졌지만, 해당 패키지들의 주간 다운로드는 수십억 회 규모였다. 며칠 뒤엔 스스로 퍼지는 npm 웜(Shai-Hulud)도 별도로 등장했다.
- xz utils 백도어(2024, CVE-2024-3094): 리눅스 압축 라이브러리에 수년간 신뢰를 쌓은 기여자가 백도어를 심은 사건. 배포 직전 한 개발자가 미세한 속도 저하를 이상하게 여겨 발견했다.
- 비유: 식당이 아니라 식재료 납품 업체에 독을 넣는 것. 그 재료를 쓰는 식당 수천 곳이 한꺼번에 당한다.
typosquatting(타이포스쿼팅) — 유명 패키지와 철자가 비슷한 가짜 이름(reqeusts, lodahs)으로 악성 패키지를 올려 오타를 노리는 것(상황 4). AI가 존재하지 않는 패키지 이름을 지어내면 공격자가 그 이름을 먼저 등록해 두는 수법(slopsquatting)도 있다 — AI 보안 주제에서 자세히.
방어 습관
- 설치 전 패키지 이름·다운로드 수·관리자·최근 변경을 확인. AI가 제안한 패키지는 특히.
- 새 버전을 바로 쓰지 않고 며칠 기다리는 설정(상황 3 같은 짧은 오염 기간을 피함).
- 설치 스크립트(postinstall) 실행을 기본으로 막는 설정 고려.
- 의존성은 적을수록 공격 표면(1번 레슨)이 작다. 몇 줄이면 될 기능에 패키지를 들이지 않는다.
- SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) — 우리 앱에 들어간 모든 부품 목록. 새 CVE가 터졌을 때 “우리도 쓰나?“를 바로 답할 수 있다.

지시 예문

“npm audit 결과를 CVSS 점수 순으로 정리하고, 각 취약점이 우리 코드에서 실제로 쓰는 기능인지(도달 가능성) 확인해서 우선순위를 매겨줘. MAJOR 버전 업데이트는 테스트 후에.”
“lockfile이 커밋돼 있는지 확인하고, CI와 배포에서 npm ci로 설치하게 바꿔줘. Dependabot도 설정해줘.”
“package.json의 의존성 중 chalk·debug 등 2025년 9월 오염 버전이 lockfile에 남아 있는지 확인해줘.”
“이 패키지를 설치하기 전에 진짜 이름이 맞는지, 다운로드 수·관리자·최근 배포 이력을 확인해줘. 비슷한 이름의 가짜 패키지일 가능성도 점검하고.”

설정 오류와 정보 노출: misconfiguration · 에러 노출 · .git · source map · 기본 계정

상황

실서비스에서 에러가 나자 화면에 코드 파일 경로, DB 쿼리, 라이브러리 버전까지 담긴 긴 에러 내용이 그대로 떴다.
누군가 우리도메인.com/.git/에 접속해 소스 코드와 커밋 기록 전체를 내려받았다. 기록 속엔 예전에 지운 API 키도 남아 있었다.
관리자 도구를 설치한 뒤 기본 비밀번호(admin/admin)를 바꾸지 않았다.
테스트용으로 만든 스토리지 버킷이 public으로 열려 있어 고객 신분증 사진이 검색엔진에 잡혔다.

용어

security misconfiguration(보안 설정 오류) — 코드 버그가 아니라 설정을 잘못(또는 기본값 그대로) 둬서 생기는 구멍. OWASP(Open Worldwide Application Security Project) Top 10의 단골 범주(1번 레슨). 바이브코딩에서 특히 흔하다 — AI는 “일단 되게” 만들려고 열어 두는 쪽을 고르기 쉽다.
information disclosure / sensitive data exposure(정보 노출) — 공격에 쓸 수 있는 정보가 새는 것. 직접 피해가 없어 보여도 다음 공격의 지도가 된다.
흔한 설정 오류 목록
- verbose error / stack trace(자세한 에러·호출 기록) 노출 — 실서비스에서 에러 상세를 사용자에게 보여줌(상황 1). 사용자에겐 “문제가 생겼어요”(웹 용어 22번 error state)만, 상세는 서버 로그·에러 추적 도구(인프라 용어 8번 Sentry)로만. debug mode(디버그 모드)는 실서비스에서 반드시 끈다.
- 노출된 .git 폴더·백업 파일 — 서버에 코드를 올릴 때 .git, .env, backup.zip, db.sql 같은 파일이 웹에서 접근 가능하게 남는 것(상황 2). git 기록엔 지운 비밀값도 남아 있다(인프라 용어 11번).
- source map(소스 맵) 공개 — 압축된 프론트엔드 코드를 원래 코드로 되돌려 보여주는 파일(웹 용어 20번 번들의 디버깅용). 실서비스에 공개돼 있으면 원본 소스 전체가 보인다. 프론트 코드는 어차피 공개된다고 보고 비밀을 넣지 않는 게 원칙이지만, 내부 API 주소·주석·로직이 드러나니 공개 여부를 의식적으로 정한다.
- default credentials(기본 계정) — 설치 직후의 admin/admin, root/root 같은 계정을 그대로 둠(상황 3). 자동화된 봇이 가장 먼저 시도한다.
- public storage(공개 저장소) — object storage 버킷을 public으로 둠(상황 4, 인프라 용어 5번). 민감 파일은 private + presigned URL(Uniform Resource Locator).
- 열린 관리 화면·DB 포트 — /admin, DB 관리 도구, DB 포트를 인터넷에 공개(2번 레슨 forced browsing, 인프라 용어 11번 방화벽).
- 넓게 열린 CORS(Cross-Origin Resource Sharing) — 쿠키 인증 API에 모든 출처 허용(웹 용어 13번).
- directory listing(폴더 목록 보기) — 주소가 폴더를 가리킬 때 파일 목록이 그대로 보이는 웹 서버 설정.
- 불필요한 기능·샘플 페이지 — 쓰지 않는 API, 테스트용 엔드포인트, 예제 페이지가 실서비스에 남음. 1번 레슨 attack surface를 넓힌다.
민감 정보가 새는 흔한 길 — 코드 밖에서도 샌다.
- URL 쿼리에 토큰·개인정보 — 주소는 브라우저 기록·서버 로그·Referrer(5번 레슨)로 남는다. 민감 값은 URL이 아니라 요청 본문·헤더로.
- 로그에 비밀번호·토큰·카드번호 — 인프라 용어 8번 마스킹.
- API 응답에 필요 이상 필드 — 화면엔 이름만 보이지만 응답엔 이메일·전화번호·해시된 비밀번호까지 들어 있음(개발자 도구로 다 보인다, 웹 용어 36번). 응답 필드도 allowlist로.
- 클라이언트 번들 속 비밀값 — NEXT_PUBLIC_ 붙은 비밀 키(웹 용어 17번).
hardening(하드닝, 보안 강화 설정) — 기본값을 안전한 쪽으로 조이는 작업 전반: 불필요한 기능 끄기, 기본 계정 제거, 에러 상세 숨기기, 보안 헤더(5번 레슨), 최소 권한. 배포 전 체크리스트로 만든다(기획 용어 3번 DoD(Definition of Done)에 포함).
- 비유: 새 아파트 입주. 집은 멀쩡해도 현관 비밀번호가 공장 초기값이고, 창문이 열려 있고, 관리비 고지서에 내 정보가 다 적힌 채 우편함 밖에 꽂혀 있으면 위험하다. 입주 첫날 하는 점검이 하드닝.

지시 예문

“실서비스 설정을 점검해줘: debug 모드, 에러 상세 노출, source map 공개 여부, 노출된 .git·.env·백업 파일, directory listing. 각각 현재 상태와 수정안을 표로.”
“API 응답에 화면에서 안 쓰는 필드(이메일, 전화번호, password_hash 등)가 섞여 나가는 곳을 찾아서 필요한 필드만 내보내게 바꿔줘.”
“URL 쿼리에 토큰이나 개인정보가 들어가는 곳을 찾아서 요청 본문이나 헤더로 옮겨줘.”
“배포 전 보안 하드닝 체크리스트를 만들어서 DoD에 추가해줘: 기본 계정 제거, 버킷 private 확인, 관리 화면 접근 제한, 보안 헤더, 에러 상세 숨김.”

파일 업로드 보안: 확장자 위장 · magic bytes · SVG · 크기 제한 · EXIF

상황

“이미지만 올릴 수 있어요”라며 확장자가 .jpg인지만 확인했는데, 누군가 shell.php.jpg처럼 이름만 바꾼 실행 파일을 올렸다.
프로필 사진으로 SVG 파일을 허용했더니, 그 이미지를 연 사람 브라우저에서 스크립트가 실행됐다.
누군가 5GB짜리 파일을 수십 번 올려 서버 디스크가 가득 차고 서비스가 멈췄다.
사용자가 올린 사진 원본을 그대로 공개했더니, 사진 속 GPS 위치 정보로 집 주소가 드러났다.

용어

unrestricted file upload(무제한 파일 업로드) — 업로드한 파일의 종류·크기·위치를 제대로 통제하지 않는 취약점. 최악의 경우 공격자가 올린 파일이 서버에서 실행되어 서버를 장악당한다(4번 레슨 code injection의 파일 버전).
확장자 · MIME(Multipurpose Internet Mail Extensions) type · magic bytes — 파일 종류를 판단하는 세 가지 단서. 앞의 둘은 사용자가 마음대로 바꿀 수 있다(상황 1).
- 확장자 — 파일 이름 끝(.jpg). 그냥 이름이라 아무렇게나 붙일 수 있다.
- MIME type — 브라우저가 요청에 “이건 image/jpeg예요”라고 적어 보내는 값. 이것도 조작 가능.
- magic bytes(파일 시그니처) — 파일 내용 맨 앞의 고유 바이트. JPEG·PNG·PDF(Portable Document Format)마다 정해져 있다. 서버가 실제 내용을 읽어 확인하는 게 더 믿을 만하다.
- 비유: 택배 상자. 송장에 “과일”이라 적혀 있어도(확장자·MIME) 열어 봐야(magic bytes) 진짜 과일인지 안다.
SVG(Scalable Vector Graphics)의 함정 — SVG는 이미지처럼 보이지만 XML(eXtensible Markup Language) 문서라서 안에 스크립트를 넣을 수 있다(상황 2, 5번 레슨 stored XSS(Cross-Site Scripting)). 사용자 업로드에선 SVG를 막거나, sanitize하거나, PNG로 변환해서 저장한다. HTML 파일 업로드도 같은 이유로 위험.
방어 원칙
- allowlist(허용 목록) — 받을 형식을 정해 둔다(jpg·png·webp만). 4번 레슨 원칙.
- 내용으로 검증 — magic bytes 확인, 이미지라면 이미지 라이브러리로 다시 열어 새로 저장(re-encoding). 숨어 있던 이상한 데이터가 떨어져 나간다.
- 크기·개수 제한 — 파일당 최대 크기, 사용자당 업로드 횟수(웹 용어 28번 rate limit). 상황 3은 인프라 용어 10번 비용 폭탄으로도 이어진다.
- 파일 이름 새로 짓기 — 사용자가 준 이름을 쓰지 않고 무작위 이름으로 저장(4번 레슨 path traversal, 이름 충돌 방지).
- 실행되지 않는 곳에 저장 — 서버 코드 폴더가 아니라 object storage(인프라 용어 5번)에, 가능하면 별도 도메인에서 서빙. 업로드 파일이 우리 사이트의 쿠키·권한과 섞이지 않는다.
- 내려줄 때 헤더 — Content-Type을 정확히, 5번 레슨 X-Content-Type-Options: nosniff, 문서류는 Content-Disposition: attachment(브라우저에서 열지 말고 다운로드하게).
- 악성코드 검사(malware scan) — 다른 사용자가 내려받는 파일(첨부파일 공유 등)이라면 업로드 시 검사.
EXIF(Exchangeable Image File Format) 메타데이터 — 사진 파일 안에 숨어 있는 촬영 정보: 기기, 촬영 시각, 그리고 GPS(Global Positioning System) 위치. 그대로 공개하면 개인정보가 샌다(상황 4). 공개용 이미지는 EXIF를 제거하고 저장한다(re-encoding하면 대개 함께 사라진다).

지시 예문

“프로필 이미지 업로드를 점검해서 고쳐줘: jpg·png·webp만 허용(magic bytes로 확인), 최대 5MB, 이미지 라이브러리로 다시 인코딩하면서 EXIF 제거, 무작위 파일 이름으로 object storage에 저장.”
“SVG와 HTML 업로드가 허용되는 곳이 있는지 찾아서 막거나 PNG로 변환하게 해줘.”
“첨부파일 다운로드 응답에 Content-Type, nosniff, Content-Disposition: attachment가 제대로 붙는지 확인해줘.”
“사용자당 업로드 rate limit과 전체 저장 용량 상한을 넣고, 상한 근처에서 알림이 오게 해줘.”

보안 검사와 기록: SAST · DAST · SCA · secret scanning · audit log

상황

지금까지 배운 취약점을 사람이 매번 눈으로 찾자니 끝이 없다. AI가 하루에 수백 줄씩 코드를 만드는데 검토가 따라가지 못한다.
API 키가 담긴 커밋을 이미 원격에 올린 뒤에야 알았다(인프라 용어 11번).
누군가 관리자 계정으로 회원 데이터를 대량으로 내려받았는데, 누가·언제·무엇을 했는지 남은 기록이 없다.
해킹당한 걸 석 달 뒤 고객 제보로 알았다.

용어

보안 검사 도구의 종류 — 사람이 다 볼 수 없으니 자동으로 찾게 한다. 서로 보는 곳이 달라 섞어 쓴다.
- SAST(Static Application Security Testing, 정적 분석) — 코드를 실행하지 않고 읽어서 위험한 패턴을 찾는다. “사용자 입력이 exec에 들어감”(4번 레슨), “dangerouslySetInnerHTML에 sanitize 없음”(5번 레슨). Semgrep, CodeQL 등. AI 기반 코드 보안 스캔도 이 계열. 비유: 설계도 검토.
- DAST(Dynamic Application Security Testing, 동적 분석) — 실행 중인 앱에 실제로 공격 요청을 보내 반응을 본다. 스테이징 환경(웹 용어 33번)에서 돌린다. 비유: 완성된 건물에 실제로 문 따기를 시도해 보는 것.
- SCA(Software Composition Analysis, 구성 요소 분석) — 의존성의 알려진 취약점(CVE(Common Vulnerabilities and Exposures)) 검사. 7번 레슨 npm audit·Dependabot이 이것.
- secret scanning(비밀값 검사) — 코드·커밋에 API 키·비밀번호가 들어갔는지 검사(상황 2). 가장 좋은 건 올리기 전에 막는 것: 커밋 직전 검사(pre-commit hook, gitleaks 등), GitHub의 push protection(비밀값이 든 push를 거부).
shift left(앞당기기) — 보안 검사를 배포 직전이 아니라 개발 초기·매 커밋으로 당기는 것. 일찍 찾을수록 고치기 싸다. 위 도구들을 CI(Continuous Integration)(웹 용어 33번)에 넣어 PR(Pull Request)마다 자동으로 돌린다(상황 1 해결).
false positive(오탐) — 도구가 문제라고 했지만 실제론 문제가 아닌 경우. 자동 검사는 오탐이 섞이니 결과를 검증하고, 반복되는 오탐은 규칙에서 제외 처리한다. 데이터 용어 9번 기저율 무시와 같은 맥락 — 경고가 너무 많으면 다 무시하게 된다(인프라 용어 8번 alert fatigue).
security logging(보안 기록) — OWASP(Open Worldwide Application Security Project) Top 10의 “기록·감시 실패”가 다루는 영역. 공격을 알아채고, 나중에 추적하려면 무엇이 일어났는지 남아 있어야 한다(상황 3·4).
- audit log(감사 로그) — 누가·언제·무엇을·어디서 했는지 바꿀 수 없게 남기는 기록. 로그인 성공·실패, 비밀번호·권한 변경, 관리자 작업, 대량 다운로드, 결제·환불. 일반 로그(인프라 용어 8번)와 달리 보존 기간이 길고 지우기 어렵게 둔다.
- 보안 이벤트 알림 — 같은 IP에서 로그인 실패 급증(3번 레슨 credential stuffing), 새 국가에서 관리자 로그인, 평소의 100배 데이터 조회 같은 이상 징후에 알림(인프라 용어 8번 alert, 데이터 용어 8번 anomaly).
- 로그에 비밀번호·토큰은 남기지 않는다(8번 레슨).
- 비유: 건물의 CCTV와 출입 기록부. 도둑을 막지는 못해도 언제 누가 들어왔는지 알게 해 주고, 수상한 움직임에 경보를 울린다. 기록이 없으면 피해 범위조차 모른다.
pentest(모의 해킹) — 허락을 받은 전문가가 실제 공격자처럼 서비스를 공격해 보는 점검. 도구가 못 찾는 논리적 구멍(2번 레슨 접근 제어 같은)을 잘 찾는다. 보안 운영 주제에서 자세히.

지시 예문

“GitHub Actions에 PR마다 SAST(Semgrep), SCA(npm audit), secret scanning이 돌게 설정해줘. high 이상이면 머지 막고, 결과는 PR 코멘트로.”
“커밋 전에 비밀값을 검사하는 pre-commit hook을 넣고, GitHub push protection도 켜줘. 그리고 git 기록 전체에 이미 들어간 비밀값이 있는지 한 번 검사해줘.”
“audit log 테이블을 만들어줘: 로그인 성공·실패, 비밀번호·권한 변경, 관리자 작업, 대량 다운로드를 who·when·what·where(IP)로 기록. 일반 사용자는 수정·삭제 불가.”
“1분에 같은 IP에서 로그인 실패 20회 이상, 관리자 계정의 새 국가 로그인 시 슬랙으로 알림 보내줘.”