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문제를 먼저 풀어볼 수도 있어요.