이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
웹 보안 수업에서 의도적으로 취약하게 만든 실습 환경에서 API 취약점 점검을 직접 해봤습니다. 인증 토큰을 조작하거나 파라미터를 바꿔서 권한 없는 데이터에 접근이 되는지 확인하는 방식이었습니다. 처음에 토큰을 수정했는데 서버가 정상 응답을 해서 인증 검증이 실제로 없었다는 걸 확인했고, 그게 꽤 충격적이었습니다. 그 실습에서 인증 누락이 얼마나 쉽게 생기는지를 직접 경험했습니다. 발견한 취약점을 리포트로 작성하는 과제도 있었는데, 처음 쓴 리포트가 설명이 너무 기술적이라서 "영향이 무엇인지 먼저 써야 한다"는 피드백을 받았습니다. 실무에서 점검 결과를 전달하는 방식도 기술 지식만큼 중요하다는 걸 그때 배웠습니다.
사이드 프로젝트에서 API를 만들고 나서 혼자 기본 취약점 점검을 해봤습니다. 인증 없이 호출 가능한 엔드포인트가 있는지, SQL 파라미터가 그대로 들어가는지, 에러 메시지에 내부 정보가 노출되는지를 순서대로 확인했습니다. 실제로 에러 메시지에 DB 테이블 이름이 그대로 나오는 걸 발견했고, 그걸 수정하면서 에러 처리가 얼마나 중요한지 실감했습니다. 내가 만든 코드를 공격자 시각으로 보는 게 처음엔 어색했는데, 취약점을 직접 찾으면서 개발할 때 어떤 부분을 주의해야 하는지 눈에 들어오기 시작했습니다. 도구를 쓴 게 아니라 수동으로 한 수준이어서 실무 점검과 차이가 있겠지만, 접근 방식은 비슷하다고 생각합니다.
보안 스터디에서 팀으로 CTF 대회에 참가했을 때 API 관련 문제를 맡았습니다. 인증 우회나 권한 상승 유형 문제에서 직접 요청을 조작하면서 어떤 파라미터를 건드리면 응답이 달라지는지 확인했습니다. 처음 문제에서 토큰 만료 검증이 없는 걸 찾았는데, 만료된 토큰으로 계속 요청을 보내보는 생각을 하는 데 20분이 걸렸습니다. 그 이후 문제들에서는 비슷한 패턴을 더 빨리 찾을 수 있었고, 점검에서도 "어디를 먼저 봐야 하는지" 감이 생겼습니다. 실무 수준과는 차이가 있지만, 취약점 유형과 접근 방식을 빠르게 익힌 경험이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.