반복되는 취약점 목록이고, 공통 뼈대는 하나입니다. 외부에서 온 입력과 요청을 신뢰하지 않는 것입니다.
OWASP Top 10
주요 취약점
| 순위 | 취약점 | 설명 | 방어 |
|---|
| 1 | Injection | SQL/NoSQL 삽입 | PreparedStatement, ORM |
| 2 | 인증 실패 | 약한 비밀번호, 세션 탈취 | MFA, 토큰 관리 |
| 3 | XSS | 악성 스크립트 삽입 | 입력 이스케이프, CSP |
| 4 | CSRF | 위조 요청 | CSRF 토큰, SameSite 쿠키 |
왜 같은 것이 반복되나
목록의 항목은 바뀌어도 원인은 대개 셋 중 하나입니다.
신뢰 경계를 잊는다. 브라우저에서 온 값은 사용자가 바꿀 수 있습니다. 숨긴 필드, 요청
머리말, 쿠키 값이 다 그렇습니다. 화면에서 막은 것은 막은 것이 아니고, 서버가 다시 검사해야
막힌 것입니다.
권한 검사를 화면에 둔다. 버튼을 숨기는 것은 권한 검사가 아닙니다. 주소를 아는 사람은
그대로 부릅니다. 그리고 남의 것을 볼 수 있는지는 요청마다 그 자원의 주인이 맞는지
확인해야 알 수 있습니다. 로그인했는지만 보는 것으로는 부족합니다.
기본값이 위험하다. 관리 화면이 열려 있거나, 오류 메시지가 내부 구조를 보여 주거나,
쓰지 않는 기능이 켜져 있는 것입니다. 새로 만든 것이 아니라 켜 둔 것을 끄지 않은 것이
문제가 됩니다.
무엇을 먼저 막나
| 순서 | 무엇 | 왜 먼저인가 |
|---|
| 1 | 서버에서 입력 검사 | 대부분의 항목이 여기서 시작한다 |
| 2 | 요청마다 자원 소유 확인 | 남의 것을 보는 사고가 가장 흔하다 |
| 3 | 비밀을 코드와 로그에서 빼기 | 한 번 새면 되돌릴 수 없다 |
의존성 갱신도 여기 들어갑니다. 우리가 쓴 코드가 아니라 가져다 쓴 것에서 나는 문제가
많고, 그것은 새로 짜서 막는 것이 아니라 버전을 올려서 막습니다.
실무 포인트
- SQL Injection: PreparedStatement는 기본, ORM 사용이 가장 안전
- XSS: 사용자 입력을 그대로 HTML에 렌더링하지 않기
- HTTPS 필수: 모든 통신 암호화
- Spring Security, Helmet.js 등 프레임워크 보안 기능 활용
Q.OWASP Top 10 중 가장 중요한 3가지는?
순위보다 우리 서비스에서 터질 확률과 피해로 고르는 것이 답입니다. 웹 백엔드에서는 보통 이 셋입니다.
| 항목 | 왜 |
|---|
| 접근 제어 실패 | 코드 한 줄을 빼먹으면 바로 남의 데이터가 열린다. 자동 탐지가 어렵다 |
| 인젝션 (SQL, 명령어) | 한 번 뚫리면 DB 전체가 노출된다 |
| 인증 실패 | 계정 탈취로 이어지고 다른 취약점의 발판이 된다 |
접근 제어를 첫째로 두는 이유는 도구로 잡히지 않기 때문입니다. 인젝션은 정적 분석과 ORM으로 상당히 걸러지지만, "이 주문이 이 사용자 것인가"는 도구가 판단할 수 없습니다.
흔한 실수: Top 10을 순서대로 외워 답하는 것. 면접에서 원하는 것은 목록 암기가 아니라 우리 스택에서 무엇이 위험한지 판단하는 근거입니다. 내부망 전용 API라면 우선순위가 완전히 달라집니다.
Q.SQL Injection을 어떻게 방지하나요?
값과 쿼리 구조를 분리하는 것이 핵심입니다. 파라미터 바인딩이 그 방법입니다.
| 조치 | 효과 |
|---|
| 파라미터 바인딩 | 값 자리는 완전히 막힌다. 1순위 |
| 식별자는 허용 목록 | 컬럼명, 정렬 방향은 바인딩이 안 된다. 목록에 없으면 거부 |
| DB 권한 최소화 | 읽기 전용 계정, 테이블 단위 권한. 뚫려도 범위를 좁힌다 |
| 오류 메시지 숨기기 | 쿼리와 스키마가 새어 나가는 것을 막는다 |
바인딩은 값이 들어갈 자리에만 씁니다. ORDER BY ? 는 동작하지 않거나 무시됩니다. 구조는 실행 계획을 세우기 전에 확정돼야 하기 때문입니다.
흔한 실수: 특수문자 이스케이프나 필터링을 1순위로 답하는 것. 우회 방법이 계속 나오고 인코딩 조합에 따라 뚫립니다. 바인딩은 값을 문법으로 해석하지 않으므로 우회할 대상이 없습니다.
Q.XSS와 CSRF 차이를 설명해주세요
누구를 속이는지가 다릅니다.
| 항목 | XSS | CSRF |
|---|
| 대상 | 브라우저가 우리 스크립트로 믿고 실행한다 | 서버가 요청을 정당한 사용자로 믿는다 |
| 공격자가 얻는 것 | 페이지 안에서 무엇이든 실행. 토큰 탈취 가능 | 특정 동작 실행. 응답은 볼 수 없다 |
| 막는 방법 | 출력 이스케이프, CSP | CSRF 토큰, SameSite 쿠키, Origin 확인 |
| 필요한 조건 | 우리 페이지에 값이 그대로 출력됨 | 사용자가 로그인 상태 |
중요한 관계가 있습니다. XSS가 있으면 CSRF 방어가 무력화됩니다. 스크립트를 실행할 수 있으면 CSRF 토큰을 읽어 정상 요청을 만들 수 있습니다. 그래서 XSS를 먼저 막습니다.
흔한 실수: CSRF를 "요청 위조"로만 설명하고 응답을 못 본다는 점을 빼는 것. 이 제약 때문에 CSRF는 상태를 바꾸는 요청에서만 문제가 됩니다.
Q.입력값 검증은 클라이언트/서버 중 어디서 해야 하나요?
서버는 필수, 클라이언트는 편의입니다. 둘 다 하되 역할이 다릅니다.
| 위치 | 목적 | 신뢰도 |
|---|
| 클라이언트 | 즉시 피드백으로 사용자 경험 개선 | 없다. 우회 가능 |
| 서버 | 데이터 정합성과 보안 | 유일한 신뢰 경계 |
클라이언트 검증을 신뢰할 수 없는 이유는 명확합니다. 개발자 도구로 코드를 바꾸거나, 브라우저 없이 API를 직접 호출하면 그냥 통과합니다.
서버에서의 검증 순서입니다.
| 순서 | 검사 | 실패 시 |
|---|
| 1 | 인증 | 토큰이 없으면 401 |
| 2 | 권한 | 자격이 없으면 403 |
| 3 | 형식 | 타입, 길이, 범위, 필수값 |
| 4 | 업무 규칙 | 잔액, 재고, 상태 전이 |
흔한 실수: 서버 검증을 프레임워크의 타입 검사로 대체했다고 보는 것. 타입이 맞아도 값이 업무 규칙을 위반할 수 있고(음수 수량, 남의 id), 그 판단은 직접 해야 합니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
보안 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.