이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 API를 개발하면서 백엔드 보안 취약점을 처음으로 의식적으로 점검한 경험이 있습니다. 초기에 사용자 입력을 그대로 쿼리에 넣었다가 SQL 인젝션 취약점이 있다는 걸 코드 리뷰에서 지적받았습니다. 그 이후 파라미터 바인딩 방식으로 쿼리를 수정하고, 인증 처리에서 JWT 토큰의 유효성 검증 로직을 꼼꼼히 검토했습니다.
보안은 기능 개발이 끝난 뒤에 추가하는 게 아니라 설계 단계부터 고려해야 한다는 걸 배웠고, 특히 사용자 입력은 어디서 들어오든 신뢰하지 않는다는 원칙을 코드에 적용했습니다. 지금도 새 API를 만들 때 OWASP Top 10 항목을 체크리스트로 훑어보는 습관을 유지하고 있습니다.
API 응답 데이터를 프런트엔드에서 그대로 innerHTML에 주입하는 코드를 리뷰에서 발견한 경험이 있습니다. 당시 팀에 XSS 취약점 위험을 공유했고, 이후 프런트엔드 코드 전수 점검을 진행해 유사 패턴 5건을 추가로 발견해 수정했습니다. 백엔드에서는 API 응답 시 출력 인코딩(Output Encoding)을 기본으로 적용하고, 신뢰할 수 없는 데이터는 절대 직접 렌더링하지 않는 원칙을 팀 코드 리뷰 체크리스트에 추가했습니다. 이후 프로젝트에서 OWASP Top 10 기준의 보안 리뷰를 개발 완료 단계에서 의무화했고, 배포 전 취약점 발견 건수가 눈에 띄게 감소했습니다. 백엔드 보안은 기능 개발 이후 점검이 아니라 설계 단계부터 고려해야 한다는 시각을 이 경험에서 갖게 됐습니다.
백엔드 API에서 일부 엔드포인트가 JWT 토큰 검증을 누락한 채 배포된 취약점을 내부 점검에서 발견했습니다. 해당 엔드포인트는 관리자 기능이었는데, 인증 없이 직접 호출하면 관리자 데이터에 접근 가능한 상태였습니다. 즉시 핫픽스를 적용하고, 전체 엔드포인트에 대해 인증 미들웨어 적용 여부를 코드로 명시하는 방식으로 재구조화했습니다. 인증이 불필요한 퍼블릭 엔드포인트도 @Public 어노테이션으로 명시적으로 표시해, 묵시적 허용이 아닌 명시적 허용 원칙으로 전환했습니다. 이 경험에서 인증 보안의 핵심은 기본값을 차단으로 두고 허용을 명시하는 설계 철학임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.