반응형
요즘 시스템은 API 중심으로 흘러간다.
그래서 보안 점검에서도 “API 인증 붙였나요?”로 끝내면 안 되는 경우가 많다.
API는 인증이 시작점이고, 실제 사고는 다른 지점에서 터지는 일이 많다.
인증 다음에 봐야 하는 것: 인가(Authorization)
인증은 “누구냐”를 확인하고, 인가는 “무엇을 할 수 있냐”를 정한다.
API 사고는 보통 인가에서 나온다.
- 본인 데이터만 조회해야 하는데 다른 사용자 데이터가 조회되는 경우
- 역할에 따라 접근 범위가 달라야 하는데 통제가 느슨한 경우
- 객체 단위 인가가 빠져서 ID만 바꾸면 다른 데이터가 보이는 경우
실무에서는 이걸 “객체 수준 접근통제” 관점으로 반드시 체크한다.
속도 제한과 남용 방지: Rate Limit은 보안이다
API는 공격자가 자동화하기 좋은 구조다.
그래서 다음 같은 공격이 현실적으로 가능해진다.
- 자격증명 대입(credential stuffing)
- 계정 열거(존재 여부 확인)
- 대량 조회/크롤링
이때 방어는 레이트리밋, 시그널 기반 차단, 이상행위 탐지가 된다.
운영 루틴이 없으면 공격을 ‘기술적으로 막을 수 있는 시간’이 줄어든다.
에러 메시지와 로그가 민감정보가 되는 순간
API는 디버깅 편의를 위해 에러 메시지를 풍부하게 내보내는 경우가 있다.
하지만 에러 메시지나 응답 바디가
- 내부 경로
- 쿼리
- 토큰
- 개인정보
를 포함하면 그 자체가 유출 통로가 된다.
그래서 API 응답의 에러 처리 표준(에러코드, 메시지 최소화)과, 서버 측 상세 로그 분리가 중요하다.
체크리스트로 정리해보는 API 보안 점검 항목
- 인증: 토큰 수명, 재발급 정책, 탈취 대응
- 인가: 역할 기반 + 객체 단위 통제
- 입력검증: 스키마 검증, 서버 측 필터링
- 레이트리밋: 구간별 제한, 계정/아이피 기반
- 로깅: 민감정보 마스킹, 접근기록 보관
- 모니터링: 비정상 패턴 탐지, 경보 기준
- 보안테스트: 주요 API에 대한 반복 점검(권한, 파라미터)
마무리
API는 “인증만 붙이면 끝”이 아니라,
인가·남용방지·로그·에러 처리까지가 같이 묶여야 안전해진다.
보안 담당자로 이직을 준비한다면, API 보안은 지금 가장 실무적으로 보여줄 수 있는 영역 중 하나라고 생각한다.
반응형