FastAPI 시니어 보안 면접

FastAPI 시니어 (7년+) 보안 7문항 조회수 28 · 2026-08-04 (화) 12:51:45
1 인증/인가
Hard

Q. FastAPI에서 JWT 기반 인증 시스템을 구축할 때, Access Token과 Refresh Token을 모두 사용하는 이중 토큰 전략의 설계 원칙과 각 토큰의 저장 위치, 만료 시간 설정 기준, 그리고 Refresh Token Rotation 전략을 어떻게 구현하시겠습니까?

토큰의 보안 수준과 사용자 경험의 균형, 그리고 토큰 탈취 시나리오를 고려해보세요.

A. 모범답안

Access Token은 짧은 만료 시간(15-30분)으로 설정하고 메모리나 httpOnly 쿠키에 저장하며, Refresh Token은 긴 만료 시간(7-30일)으로 설정하고 httpOnly, Secure, SameSite 속성이 적용된 쿠키에 저장합니다. Refresh Token Rotation은 토큰 갱신 시마다 새로운 Refresh Token을 발급하고 이전 토큰을 무효화하는 방식으로 구현하며, Redis에 토큰 패밀리 ID를 저장하여 재사용 탐지 시 해당 패밀리의 모든 토큰을 무효화합니다. 데이터베이스에는 Refresh Token의 해시값만 저장하고, 토큰 발급 시각과 디바이스 정보를 함께 기록하여 이상 패턴을 감지할 수 있도록 합니다. FastAPI의 Depends를 활용하여 토큰 검증 로직을 의존성으로 분리하고, 각 엔드포인트에서 필요한 권한 수준을 선언적으로 명시합니다.

핵심 포인트
  • • Access Token은 짧은 만료 시간, Refresh Token은 긴 만료 시간으로 차별화
  • • Refresh Token Rotation으로 재사용 공격 방지
  • • httpOnly, Secure, SameSite 쿠키 속성 활용
  • • 토큰 패밀리 추적을 통한 탈취 감지 메커니즘
답변에 넣으면 좋은 키워드
JWT Refresh Token Rotation httpOnly 쿠키 토큰 패밀리 Redis 재사용 탐지
실무에서는

대규모 사용자를 가진 서비스에서 토큰 탈취로 인한 계정 도용을 방지하고, 사용자 경험을 해치지 않으면서 보안 수준을 높이는 상황에서 사용됩니다.

Follow-up 질문

만약 마이크로서비스 아키텍처에서 여러 서비스가 동일한 JWT를 검증해야 한다면, 토큰 검증 로직을 어떻게 중앙화하고 성능을 최적화하시겠습니까?

2 웹 취약점
Hard

Q. FastAPI 애플리케이션에서 SQL Injection을 방어하기 위한 다층 방어 전략을 설명해주세요. SQLAlchemy ORM 사용 시에도 발생할 수 있는 SQL Injection 취약점 시나리오와, Raw Query를 사용해야 하는 상황에서의 안전한 구현 방법을 포함해주세요.

ORM을 사용해도 텍스트 기반 쿼리나 동적 쿼리 생성 시 취약점이 발생할 수 있습니다.

A. 모범답안

SQLAlchemy ORM의 파라미터화된 쿼리를 기본으로 사용하되, text() 함수로 Raw Query 작성 시 반드시 바인딩 파라미터를 사용하고 문자열 포맷팅이나 연결을 절대 사용하지 않습니다. 동적 테이블명이나 컬럼명이 필요한 경우 화이트리스트 검증을 통해 허용된 값만 사용하도록 제한하고, 사용자 입력을 직접 쿼리에 포함하지 않습니다. 데이터베이스 사용자 권한을 최소화하여 DROP, TRUNCATE 등 위험한 명령 실행 권한을 제거하고, 애플리케이션별로 별도 DB 계정을 사용합니다. Pydantic 모델을 활용하여 입력 데이터의 타입과 형식을 검증하고, 특수문자나 SQL 키워드가 포함된 입력에 대해 추가 검증을 수행합니다. WAF나 데이터베이스 방화벽을 통해 비정상적인 쿼리 패턴을 탐지하고, 쿼리 로깅과 모니터링을 통해 의심스러운 활동을 추적합니다.

핵심 포인트
  • • 파라미터화된 쿼리와 바인딩 파라미터 사용
  • • 동적 식별자는 화이트리스트 검증
  • • 데이터베이스 권한 최소화 원칙
  • • Pydantic을 통한 입력 검증과 타입 안정성
답변에 넣으면 좋은 키워드
파라미터화된 쿼리 바인딩 파라미터 화이트리스트 최소 권한 Pydantic 검증 SQLAlchemy
실무에서는

레거시 시스템 통합이나 복잡한 분석 쿼리 작성 시 Raw Query를 사용해야 하는 상황에서 안전하게 구현해야 할 때 필요합니다.

Follow-up 질문

NoSQL 데이터베이스를 사용하는 경우 NoSQL Injection을 방어하기 위한 전략은 어떻게 다르며, MongoDB를 사용할 때 주의해야 할 점은 무엇입니까?

3 CORS 및 CSRF
Medium

Q. FastAPI에서 CORS 설정 시 allow_origins에 와일드카드(*)를 사용하는 것이 위험한 이유와, 프론트엔드가 여러 도메인에서 배포되는 경우 안전하게 CORS를 구성하는 방법을 설명해주세요. 또한 CSRF 공격을 방어하기 위한 추가 조치는 무엇입니까?

인증 정보를 포함한 요청과 와일드카드의 관계, 그리고 SameSite 쿠키 속성을 고려해보세요.

A. 모범답안

와일드카드를 사용하면 모든 출처에서의 요청을 허용하게 되어 악의적인 사이트에서도 API를 호출할 수 있으며, credentials를 true로 설정할 수 없어 인증 쿠키를 전송할 수 없습니다. 여러 도메인을 지원해야 한다면 환경 변수로 허용된 도메인 리스트를 관리하고, 정규표현식 패턴으로 서브도메인을 검증하는 커스텀 미들웨어를 구현합니다. CSRF 방어를 위해 쿠키에 SameSite=Lax 또는 Strict 속성을 설정하여 크로스 사이트 요청에서 쿠키 전송을 제한하고, 상태 변경 요청에는 CSRF 토큰을 검증하는 미들웨어를 추가합니다. API가 주로 사용되는 경우 Double Submit Cookie 패턴을 적용하거나, 커스텀 헤더(X-Requested-With)를 요구하여 단순 요청이 아닌 프리플라이트 요청을 유도합니다.

핵심 포인트
  • • 와일드카드 사용 시 credentials 전송 불가 및 보안 위험
  • • 환경 변수와 정규표현식을 통한 동적 도메인 검증
  • • SameSite 쿠키 속성으로 CSRF 기본 방어
  • • CSRF 토큰 또는 커스텀 헤더를 통한 추가 검증
답변에 넣으면 좋은 키워드
CORS 와일드카드 SameSite CSRF 토큰 Double Submit Cookie 프리플라이트
실무에서는

마이크로프론트엔드 아키텍처나 다중 환경(개발, 스테이징, 프로덕션) 배포 시 각 환경의 프론트엔드 도메인에서 안전하게 API를 호출해야 할 때 사용됩니다.

Follow-up 질문

모바일 앱과 웹 클라이언트가 동일한 API를 사용하는 경우, 각 플랫폼의 특성을 고려한 인증 및 CORS 전략은 어떻게 다르게 가져가야 합니까?

4 암호화 및 해싱
Hard

Q. FastAPI 애플리케이션에서 사용자 비밀번호를 저장할 때 bcrypt, argon2, scrypt 중 어떤 알고리즘을 선택하시겠습니까? 각 알고리즘의 특징과 트레이드오프, 그리고 비밀번호 해싱 시 고려해야 할 솔트, work factor, 메모리 하드니스 개념을 설명해주세요.

GPU 기반 공격에 대한 저항성과 서버 리소스 사용량의 균형을 생각해보세요.

A. 모범답안

현재는 argon2id를 권장하는데, 이는 사이드채널 공격에 강한 argon2i와 GPU 크래킹에 강한 argon2d의 장점을 결합한 알고리즘이기 때문입니다. bcrypt는 검증된 알고리즘이지만 메모리 하드니스가 약해 GPU 병렬 공격에 상대적으로 취약하고, scrypt는 메모리 하드니스가 강하지만 구현 복잡도가 높습니다. 솔트는 각 비밀번호마다 고유한 랜덤 값을 생성하여 레인보우 테이블 공격을 방어하며, work factor는 해싱 연산의 반복 횟수나 메모리 사용량을 조절하여 무차별 대입 공격의 비용을 증가시킵니다. 메모리 하드니스는 해싱 과정에서 많은 메모리를 요구하도록 설계하여 GPU나 ASIC 기반 병렬 공격을 어렵게 만드는 특성입니다. FastAPI에서는 passlib 라이브러리를 사용하여 argon2를 구현하고, work factor는 서버 응답 시간이 250-500ms 정도가 되도록 조정하며, 향후 하드웨어 성능 향상에 대비해 주기적으로 재해싱 전략을 수립합니다.

핵심 포인트
  • • argon2id가 사이드채널 공격과 GPU 크래킹 모두에 강함
  • • 솔트로 레인보우 테이블 공격 방어
  • • work factor로 무차별 대입 공격 비용 증가
  • • 메모리 하드니스로 병렬 공격 저항성 확보
답변에 넣으면 좋은 키워드
argon2id bcrypt 솔트 work factor 메모리 하드니스 passlib
실무에서는

수백만 명의 사용자를 가진 서비스에서 비밀번호 데이터베이스 유출 시에도 실제 비밀번호가 노출되지 않도록 보호해야 할 때 필요합니다.

Follow-up 질문

기존 시스템에서 MD5나 SHA-1로 저장된 비밀번호를 안전한 알고리즘으로 마이그레이션하는 전략을 수립한다면 어떻게 진행하시겠습니까?

5 개인정보 보호
Hard

Q. FastAPI 기반 서비스에서 GDPR과 개인정보보호법을 준수하기 위한 개인정보 처리 아키텍처를 설계해야 합니다. 데이터 최소화, 목적 제한, 저장 기간 제한 원칙을 구현하는 방법과, 사용자의 삭제 요청(Right to be Forgotten)을 처리할 때 백업 데이터, 로그, 분석 데이터를 어떻게 다루시겠습니까?

개인정보의 식별 가능성과 비즈니스 요구사항의 균형, 그리고 가명처리와 익명처리의 차이를 고려하세요.

A. 모범답안

개인정보는 수집 시점에 명시적 동의를 받고 Pydantic 모델에 개인정보 필드를 명확히 표시하여 데이터 흐름을 추적하며, 필수 정보와 선택 정보를 분리하여 최소한만 수집합니다. 민감 정보는 별도 테이블에 암호화하여 저장하고, 비즈니스 로직에서는 암호화된 상태로 처리하거나 필요한 시점에만 복호화합니다. 저장 기간 제한을 위해 데이터별 TTL을 설정하고, 백그라운드 작업으로 만료된 데이터를 자동 삭제하거나 익명화하는 스케줄러를 구현합니다. 삭제 요청 처리 시 운영 데이터베이스는 즉시 삭제하고, 백업에는 삭제 마커를 기록하여 복원 시 제외되도록 하며, 로그는 개인식별정보를 마스킹하거나 해시값으로 대체합니다. 분석 데이터는 수집 시점부터 개인을 식별할 수 없도록 집계하거나 k-익명성을 보장하는 방식으로 처리하고, 법적 보관 의무가 있는 데이터는 가명처리하여 별도 저장소에 격리합니다.

핵심 포인트
  • • 수집 시점부터 명시적 동의와 데이터 최소화 원칙 적용
  • • 민감 정보 암호화 및 별도 테이블 관리
  • • TTL 기반 자동 삭제 및 익명화 프로세스
  • • 삭제 요청 시 백업, 로그, 분석 데이터 각각의 처리 전략
답변에 넣으면 좋은 키워드
GDPR 데이터 최소화 가명처리 익명화 Right to be Forgotten k-익명성
실무에서는

유럽이나 한국 시장을 대상으로 하는 서비스에서 규제 준수 실패 시 막대한 과징금을 피하고, 사용자 신뢰를 확보해야 할 때 필수적입니다.

Follow-up 질문

마이크로서비스 아키텍처에서 여러 서비스에 분산된 개인정보를 사용자 삭제 요청 시 일관되게 처리하기 위한 오케스트레이션 전략은 무엇입니까?

6 API 보안
Medium

Q. FastAPI로 구축한 공개 API에서 Rate Limiting과 API Throttling을 구현해야 합니다. 사용자 인증 여부, 구독 플랜, IP 주소 등 다양한 기준으로 차등화된 제한을 적용하는 방법과, 분산 환경에서 일관된 Rate Limiting을 보장하는 방법을 설명해주세요.

Redis를 활용한 분산 카운터와 Token Bucket, Leaky Bucket 알고리즘을 고려해보세요.

A. 모범답안

FastAPI의 미들웨어나 Depends를 활용하여 요청마다 사용자 식별자를 추출하고, Redis의 INCR과 EXPIRE 명령을 조합하여 시간 윈도우별 요청 횟수를 추적합니다. 인증된 사용자는 JWT 클레임의 사용자 ID와 구독 플랜을 기준으로 제한을 적용하고, 미인증 사용자는 IP 주소를 기준으로 더 엄격한 제한을 적용합니다. Token Bucket 알고리즘을 구현하여 버스트 트래픽을 허용하면서도 평균 요청률을 제어하고, Redis의 Sorted Set이나 Lua 스크립트를 사용하여 원자적으로 토큰 소비와 갱신을 처리합니다. 분산 환경에서는 Redis Cluster를 사용하거나 일관된 해싱으로 특정 사용자의 요청이 동일한 Redis 노드로 라우팅되도록 하여 카운터 일관성을 보장합니다. 제한 초과 시 429 상태 코드와 함께 Retry-After 헤더를 반환하고, X-RateLimit-Limit, X-RateLimit-Remaining 헤더로 클라이언트에게 현재 상태를 알립니다.

핵심 포인트
  • • 사용자 식별자별 차등화된 제한 정책
  • • Redis 기반 분산 카운터로 일관성 보장
  • • Token Bucket 알고리즘으로 버스트 트래픽 허용
  • • 표준 헤더로 클라이언트에게 제한 정보 제공
답변에 넣으면 좋은 키워드
Rate Limiting Token Bucket Redis 분산 카운터 429 상태 코드 Retry-After
실무에서는

공개 API를 제공하는 서비스에서 무료 사용자의 과도한 사용을 제한하고, 유료 사용자에게는 더 높은 한도를 제공하여 수익화하는 상황에서 사용됩니다.

Follow-up 질문

DDoS 공격이 감지되었을 때 정상 사용자의 서비스 이용은 보장하면서 공격 트래픽만 차단하기 위한 동적 Rate Limiting 전략은 무엇입니까?

7 보안 모니터링
Hard

Q. FastAPI 애플리케이션에서 보안 이벤트를 실시간으로 탐지하고 대응하기 위한 모니터링 시스템을 구축해야 합니다. 로그인 실패, 비정상적인 API 호출 패턴, 권한 상승 시도 등을 탐지하는 방법과, 로그에 민감 정보가 노출되지 않도록 하는 전략을 설명해주세요.

구조화된 로그와 상관 분석, 그리고 로그 마스킹과 감사 추적의 균형을 생각해보세요.

A. 모범답안

FastAPI의 미들웨어에서 모든 요청과 응답을 가로채어 사용자 ID, IP, 엔드포인트, 상태 코드, 응답 시간을 JSON 형식의 구조화된 로그로 기록하고, ELK 스택이나 Datadog으로 전송합니다. 로그인 실패는 동일 IP나 사용자 ID에서 일정 시간 내 N회 이상 발생 시 알림을 트리거하고, 해당 계정이나 IP를 임시 차단하는 자동 대응 로직을 구현합니다. 비정상적인 API 호출 패턴은 사용자별 평소 행동 기준선을 학습하여 급격한 호출 증가, 새로운 엔드포인트 접근, 비정상 시간대 활동을 탐지합니다. 권한 상승 시도는 403 응답이 반복되거나 관리자 전용 엔드포인트에 대한 무단 접근 시도를 추적하여 보안팀에 즉시 알립니다. 민감 정보 보호를 위해 요청/응답 본문의 비밀번호, 토큰, 카드번호 등은 정규표현식으로 탐지하여 마스킹하고, 개인식별정보는 해시값으로 대체하되 감사 추적을 위해 원본과의 매핑 테이블은 암호화하여 별도 저장합니다.

핵심 포인트
  • • 구조화된 로그로 자동화된 분석 가능
  • • 행동 기준선 기반 이상 탐지
  • • 로그인 실패와 권한 상승 시도의 실시간 탐지 및 대응
  • • 민감 정보 마스킹과 감사 추적의 균형
답변에 넣으면 좋은 키워드
구조화된 로그 행동 기준선 이상 탐지 로그 마스킹 감사 추적 SIEM
실무에서는

금융이나 의료 등 규제가 엄격한 산업에서 보안 사고 발생 시 신속한 대응과 사후 분석을 위한 증거를 확보해야 할 때 필수적입니다.

Follow-up 질문

제로데이 취약점이 발견되어 긴급 패치가 필요한 상황에서, 패치 배포 전까지 임시로 공격을 완화하기 위한 WAF 규칙이나 애플리케이션 레벨 방어 전략은 무엇입니까?

댓글 0

로그인 후 댓글을 작성할 수 있습니다.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!