이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
포트폴리오 프로젝트에서 게시판 기능을 만들 때 처음에는 프론트에서 폼 검증만 하고 백엔드에서 검증을 하지 않았습니다. 그러나 브라우저 개발자 도구로 요청을 직접 보내면 검증이 우회된다는 사실을 알게 되었습니다. 빈 제목이나 1만 자 이상의 본문을 그대로 DB에 넣는 것이 가능했습니다. 이후 백엔드에서도 입력 길이, 허용 문자, 빈 값을 모두 검사하도록 추가하였습니다.
프론트 검증은 사용자 편의를 위한 것이고, 백엔드 검증이 실제 방어선이라는 것을 배웠습니다. 클라이언트에서 온 데이터는 항상 신뢰할 수 없다는 원칙이 생겼습니다. 이후 모든 API 엔드포인트에 입력 검증 레이어를 우선 작성하는 습관이 생겼습니다.
개인 프로젝트를 배포하고 나서 에러가 나면 스택 트레이스 전체가 브라우저에 표시됐어요. 파일 경로, DB 구조 같은 내부 정보가 그대로 노출됐어요. 보안 공부를 하면서 이게 공격자에게 내부 구조를 알려주는 것과 같다는 걸 이해했어요. 에러 핸들러를 만들어서 사용자에게는 '오류가 발생했습니다'만 보여주고 실제 에러는 서버 로그에만 기록하도록 수정했어요.
에러 메시지도 공격 표면이 될 수 있다는 걸 이때 배웠어요. 작은 프로젝트라도 외부에 배포할 때는 에러 응답을 꼭 확인하는 습관이 생겼어요. 이 경험 덕분에 한 단계 성장할 수 있었습니다. 그 과정이 값진 배움이었습니다.
학교 웹 프로그래밍 수업 프로젝트에서 로그인 기능을 만들 때 SQL을 문자열로 직접 조합했어요. 수업에서 SQL 인젝션 개념을 배우고 나서 내 코드에 적용해보니 admin' --를 입력하면 로그인이 통과됐어요. 즉시 파라미터 바인딩 방식으로 수정했어요.
쿼리 구조와 데이터를 분리하는 것이 핵심이었어요. 이후 전체 코드를 훑어보니 같은 패턴이 3군데 더 있었어요. 모두 수정하면서 취약점은 한 군데에만 있지 않다는 걸 배웠어요. 이제는 DB 쿼리를 작성할 때 파라미터 바인딩을 기본으로 쓰고 있고, 직접 문자열을 이어붙이는 코드가 보이면 먼저 의심하게 됐어요.
그 과정이 값진 배움이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.