이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
가장 잘 이해하고 있는 취약점은 SQL Injection입니다. 수업에서 직접 실습하면서 입력값이 쿼리로 그대로 삽입될 때 어떤 일이 발생하는지를 확인했습니다. 공격자가 ' OR 1=1 -- 같은 패턴으로 인증을 우회하거나 전체 테이블을 덤프할 수 있다는 점이 인상 깊었습니다. 대응 방법으로는 Prepared Statement 사용과 입력값 검증이 핵심이고, ORM을 사용하더라도 Raw Query를 직접 쓰는 부분은 별도로 점검해야 합니다. 이 취약점이 여전히 Top 10에 있는 이유는 개발자가 빠르게 구현할 때 실수하기 쉬운 패턴이기 때문이라고 생각합니다.
SQL Injection이 오래된 취약점임에도 여전히 발생하는 이유를 이해하고, 개발 과정에서 이 패턴이 나타나지 않도록 적극적으로 검토하겠습니다.
접근 제어 실패(Broken Access Control)를 가장 깊게 이해하고 있는 취약점으로 꼽겠습니다. 2021년 기준 OWASP Top 10에서 1위로 올라선 항목이고, 실제로 많은 서비스에서 자주 발견되는 패턴이기도 합니다.
발생 원리는 단순합니다. 서버가 인증(Authentication)과 인가(Authorization)를 혼동하거나, URL을 직접 변조해 다른 사용자의 리소스에 접근할 때 막지 못하는 구조에서 나타납니다. 예를 들어 /api/users/1001/profile을 /api/users/1002/profile로 바꿔도 응답이 돌아온다면, 수평적 권한 상승이 이미 발생하고 있는 것입니다.
대응 방법으로는 모든 요청마다 서버 측에서 권한을 검증하는 것이 기본이고, 프론트엔드에서 메뉴를 숨기는 것만으로는 방어가 안 됩니다. 프로젝트에서 최소 권한 원칙(Principle of Least Privilege)을 API 설계 단계에서 반영하면 사후 패치보다 훨씬 안전한 구조가 만들어진다고 느꼈습니다.
이 취약점이 지속적으로 상위에 오르는 이유는 개발 속도 압박 속에서 권한 검증 로직이 흐릿하게 구현되는 경우가 반복되기 때문이라고 생각합니다.
암호화 실패(Cryptographic Failures)를 선택하겠습니다. 이름 자체보다 실제로 어디서 실수가 나오는지를 알고 나서 이 취약점이 더 넓게 보이기 시작했습니다.
발생 원리를 보면, 민감한 데이터를 평문으로 전송하거나 취약한 알고리즘(MD5·SHA-1)으로 저장하는 경우가 대표적입니다. 특히 HTTPS를 적용했더라도 내부 서비스 간 통신에서는 HTTP를 사용하는 패턴이 자주 보이는데, 이 구간이 노출 지점이 됩니다.
대응 방법은 크게 두 갈래입니다. 전송 구간에서는 TLS 1.2 이상을 강제하고 인증서 검증을 우회하는 설정은 제거해야 합니다. 저장 구간에서는 비밀번호는 bcrypt나 Argon2처럼 적응형 해시 함수를 사용하고, 카드 번호나 주민등록번호 같은 민감 필드는 AES-256으로 암호화해 저장하는 구조가 필요합니다.
이 취약점은 도구 선택보다 설계 시점에서의 인식이 더 중요하다는 것을 느꼈습니다. 어떤 데이터가 민감한지 먼저 분류하지 않으면, 뒤늦게 암호화를 추가하는 것이 훨씬 어려워집니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.