취약점 정의를 외웠는지가 아니라, 바인딩으로 못 막는 자리에서 무엇을 어떻게 끊는지를 판단할 수 있는지를 가른다.
SQL 인젝션은 사용자 입력이 SQL 문자열에 그대로 결합돼 쿼리 구조 자체가 바뀌는 취약점이다. 공격자는 조건 우회·UNION 조회·데이터 변조 페이로드를 흘려 인증을 건너뛰거나 데이터를 통째로 꺼낸다. 방어의 본체는 PreparedStatement·바인드 변수처럼 값과 쿼리 구조를 분리 하는 것 하나다. 그 위에 ORM·입력 검증·최소 권한 계정·에러 메시지 가림을 다층으로 깔아 사고 반경을 좁힌다.
문자열 결합으로 짜인 검색 쿼리를 PreparedStatement·MyBatis #{} 로 바꿔본 경험이 있다면, 무엇을 바인딩으로 풀고 무엇을 화이트리스트로 끊었는지 그대로 답변에 녹일 수 있다
동적 정렬·필터를 받는 목록 API를 만든 경험이 있다면, 컬럼명을 enum/화이트리스트로 매핑한 이유와 그 결정의 트레이드오프를 설명할 수 있다
운영 계정 권한을 줄이거나 읽기 전용 계정으로 조회 API를 분리했던 경험이 있다면, 인젝션 사고 반경을 권한 모델로 어떻게 좁혔는지 연결할 수 있다
보안 점검·취약점 리포트에서 SQLi 케이스를 받아본 적이 있다면, 어떤 패턴이 잡혔고 무엇을 코드 컨벤션으로 끌어올렸는지 답변 후반에 붙일 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.