검색어를 SQL 문자열에 이어 붙인 코드가 위험합니다. 파라미터 바인딩으로 무엇을 막고 동적 식별자는 어떻게 처리하나요?

사용자 검색어를 SQL 문자열에 이어 붙이면 입력이 데이터가 아니라 SQL 문법으로 해석될 수 있습니다. 따옴표로 문자열을 닫고 조건이나 명령을 추가하는 입력이 들어오면 원래 한 행 검색이 다수 행 조회·변경으로 바뀔 수 있습니다. 파라미터 바인딩은 SQL 구조를 먼저 준비하고 값은 별도 매개변수로 전달해 값 안의 특수 문자가 연산자로 해석되지 않게 합니다. 예를 들어 WHERE username = ? 구조를 고정하고 드라이버에 username 값을 바인딩합니다.

값과 SQL 구조를 분리합니다

Prepared Statement는 반복 실행에서 파싱·계획 비용을 줄일 수 있지만 보안의 핵심은 성능이 아니라 코드와 값의 분리입니다. 드라이버가 문자열·숫자·날짜 타입을 전달하므로 직접 인용하고 escape하는 실수를 줄일 수 있습니다. ORM을 쓰더라도 raw SQL 조각, 로그 검색, migration·관리 도구가 문자열 연결을 하지 않는지 확인하겠습니다. 파라미터화는 입력을 안전한 값으로 만들 뿐 행 소유권이나 인가를 자동으로 추가하지 않습니다.

테이블명·컬럼명·정렬 방향 같은 식별자는 일반적인 값 파라미터로 바인딩할 수 없습니다. ORDER BY ?가 임의 컬럼을 선택하게 된다고 기대하면 안 됩니다. 동적 식별자가 필요하면 애플리케이션의 논리 이름을 허용된 실제 컬럼명으로 매핑하고, 허용되지 않은 값은 거부합니다. 정렬 방향은 asc·desc처럼 별도 열거값으로 검사합니다. 드라이버의 식별자 인용 API가 있어도 사용자 문자열 전체를 검증 없이 넘기는 설계에 의존하지 않겠습니다.

특수 의미와 권한은 별도 문제입니다

LIKE에서 %와 _는 파라미터로 바인딩해도 와일드카드 의미를 가집니다. 문자 그대로 검색할지 패턴을 허용할지 정하고, 문자 검색이면 escape 규칙과 ESCAPE 절을 적용합니다. IN 목록은 드라이버가 지원하는 배열 파라미터나 항목별 placeholder를 사용해 값으로 전달합니다. 바인딩이 SQL injection을 막아도 테넌트 ID와 현재 사용자 소유권 조건을 빠뜨리면 다른 사람의 행을 조회하는 인가 오류가 됩니다.

PostgreSQL·SQL Server·MySQL 드라이버는 서버 측 준비, 클라이언트 측 에뮬레이션, 식별자·배열 바인딩의 세부 계약이 다를 수 있습니다. 실제 드라이버 버전에서 파라미터가 SQL 구조와 분리되는지 확인하고, 실행 계획과 오류 메시지에는 원문 민감 입력을 남기지 않겠습니다. 테스트는 따옴표·주석·와일드카드·유니코드 입력, 동적 정렬 허용 목록, 테넌트 경계를 검증합니다. 안전한 구현은 파라미터화 하나가 아니라 값 바인딩, 구조 허용 목록, 인가, 오류·로그 비노출을 함께 갖춥니다.

파라미터화가 적용됐는지는 정상 검색만으로 확인할 수 없습니다. 입력값에 따옴표·주석·개행·유니코드와 LIKE 와일드카드를 넣어도 SQL 구조가 바뀌지 않는지, 허용 목록 밖 정렬 필드가 거부되는지 테스트하겠습니다. DB 계정 권한을 최소화해 injection이 발생해도 DROP·대량 변경까지 이어지지 않게 하는 방어 심층화도 필요합니다. 오류 응답은 내부 SQL을 숨기되 추적 ID로 운영자가 원인을 찾게 하겠습니다.