이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트를 깃허브에 올릴 때 API 키를 코드에 직접 써놓은 것을 모르고 push했습니다. 30분 후에 해당 서비스에서 이상한 요금 알림이 왔고, GitHub의 시크릿 스캔 경고도 받았습니다. 즉시 키를 재발급하고 커밋 히스토리에서 제거하는 작업을 진행했습니다.
git filter-branch로 히스토리를 지웠는데 이 과정에서 강제 push가 필요했습니다. 이후로는 `.env` 파일과 `.gitignore` 설정을 프로젝트 생성 첫 단계에서 하는 습관이 생겼습니다. 또한 git-secrets 같은 pre-commit 훅도 개인 프로젝트에 설치했습니다.
보안은 나중에 생각하면 이미 늦다는 것을 직접 경험했습니다.
포트폴리오 리뷰를 받다가 사용자 입력값을 innerHTML로 바로 넣는 코드가 있다는 지적을 받았어요. 당시엔 그게 왜 위험한지 몰랐어요. 멘토가 <img src=x onerror=alert(1)>를 입력창에 넣어서 알림창이 뜨는 걸 보여줬을 때 충격이었어요.
textContent를 써야 한다는 것을 그때 처음 배웠어요. 전체 코드를 훑어보니 3군데에서 같은 패턴이 있었어요. 모두 수정하면서 사용자 입력이 들어가는 부분은 항상 textContent나 라이브러리의 sanitize 함수를 쓰는 원칙을 세웠어요. 보안 취약점은 의도적으로 공격하려는 마음으로 내 코드를 바라봐야 보인다고 배웠어요.
보안 관련 책을 읽다가 SQL 인젝션 패턴을 공부했어요. 마침 오래된 개인 프로젝트에 로그인 기능이 있었는데, 코드를 보니 사용자 입력을 문자열로 직접 쿼리에 이어붙이는 방식이었어요. ' OR '1'='1을 입력하면 로그인이 통과될 수 있는 코드였어요. 즉시 파라미터 바인딩 방식으로 수정했어요. 이후 프로젝트 전체를 검색해서 비슷한 패턴이 2군데 더 있었고 모두 수정했어요.
보안 공부가 내 코드를 다르게 보게 만들어줬어요. 취약점은 만들 때 모르는 게 아니라 알게 되면 바로 보인다는 걸 느꼈어요. 앞으로도 꾸준히 공부해서 코드 리뷰할 때 이런 부분을 잡아내고 싶어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.