코드 정찰 분석 프롬프트

1. 실행 요약

이 API는 관리자 페이지에서 q 검색어를 받아 users 테이블의 이름 또는 이메일에 부분 일치하는 사용자를 조회하고 JSON으로 반환합니다.

다만 현재 상태는 프로덕션 배포에 부적합합니다. 특히 사용자 입력을 SQL 문자열에 직접 삽입하고 있어 심각한 SQL Injection 위험이 있습니다.

2. 논리 흐름

1. req.query.q에서 검색어를 가져옵니다.
2. 검색어를 SQL 문자열에 직접 결합합니다.
3. name 또는 email에 LIKE '%검색어%' 조건을 적용합니다.
4. 데이터베이스 조회 결과를 JSON으로 반환합니다.

데이터 흐름은 다음과 같습니다.

HTTP query parameter → SQL 문자열 조합 → DB 조회 → JSON 응답

q가 없거나 악의적인 값이어도 별도 검증 없이 DB 계층까지 전달됩니다.

3. 문서화 및 가독성

• 품질 평가: Poor
• 신규 개발자가 안전하게 수정하기까지: 약 1~2일
  SQL, 관리자 권한 모델, 개인정보 정책, DB 드라이버 동작을 확인해야 합니다.

주요 문제는 다음과 같습니다.

• 라우트의 인증·인가 전제가 코드상 드러나지 않음
• SQL 쿼리 목적과 반환 필드에 대한 설명 없음
• err, rows만으로는 실패 처리 의도가 불명확함
• 데이터베이스 로직과 HTTP 응답 로직이 한 함수에 결합됨
• keyword라는 이름은 검색 대상과 입력 제약을 설명하지 못함
• 에러 발생 후에도 정상 응답을 시도함

4. 성숙도 평가

• 분류: Prototype 또는 Early-stage
• Production-ready 여부: 아님

근거:

• SQL Injection 방어 없음
• 입력 검증과 길이 제한 없음
• 인증·인가가 보장되는지 불명확함
• DB 오류 시 상태 코드가 변경되지 않음
• 로깅이 부적절하고 민감한 쿼리 정보가 노출될 가능성 있음
• 페이지네이션과 결과 제한 없음
• 테스트 가능한 서비스 계층이 없음
• 이메일·전화번호 등 개인정보를 무조건 반환함

5. 위협 모델 및 엣지 케이스

치명적: SQL Injection

const sql = `... LIKE '%${keyword}%' ...`;

공격자가 q에 SQL 문법을 주입할 수 있습니다. 이는 OWASP Top 10의 Injection 및 CWE-89에 해당합니다.

예를 들어 입력값에 작은따옴표나 추가 SQL 조건이 포함되면 원래 의도와 다른 쿼리가 실행될 수 있습니다.

반드시 파라미터 바인딩을 사용해야 합니다.

const pattern = `%${keyword}%`;
const sql = `
  SELECT id, name, email, phone
  FROM users
  WHERE name LIKE ? OR email LIKE ?
  LIMIT 50
`;

db.query(sql, [pattern, pattern], ...);

단, LIKE의 %와 _를 사용자가 검색 문법으로 악용하지 못하게 하려면 별도의 wildcard escaping도 검토해야 합니다.

높음: 인증·인가 불명확

경로가 /admin이어도 자동으로 관리자 권한이 보장되지는 않습니다. 일반 사용자가 접근할 수 있다면 개인정보 조회 API가 됩니다.

• 관리자 인증 미들웨어 적용
• 관리자 역할 확인
• 감사 로그 기록
• 세션·토큰 만료 및 CSRF 정책 검토

높음: 개인정보 과다 노출

응답에 email, phone이 포함됩니다. 관리자에게도 필요한 필드만 반환해야 하며, 화면 목적에 따라 전화번호 마스킹을 적용하는 것이 안전합니다.

예:

{
  "id": 123,
  "name": "홍길동",
  "email": "hong***@example.com",
  "phone": "010-****-1234"
}

중간: DB 오류를 정상 응답으로 처리

현재는 오류를 출력한 뒤에도 다음 코드가 실행됩니다.

if (err) console.log(err);
res.json(rows);

이 경우 rows가 undefined이거나 내부 동작이 노출될 수 있습니다. 클라이언트에는 일반화된 오류를 반환해야 합니다.

if (err) {
  req.log.error({ err }, 'user search failed');
  return res.status(500).json({ error: '사용자 검색에 실패했습니다.' });
}

중간: 무제한 검색 및 성능 문제

LIKE '%keyword%'는 일반적인 B-tree 인덱스를 사용하지 못할 가능성이 높아 대규모 테이블에서 Full Table Scan이 발생할 수 있습니다.

추가 문제:

• 빈 검색어가 전체 사용자 조회로 동작할 수 있음
• 결과 개수 제한 없음
• 페이지네이션 없음
• 매우 긴 검색어로 DB 부하 유발 가능
• 동시에 많은 요청이 들어오면 검색 API가 DB를 압박할 수 있음

기타 엣지 케이스

• q가 없는 경우
• q가 배열 형태인 경우
• 빈 문자열 또는 공백만 있는 경우
• 지나치게 긴 입력값
• %, _, \가 포함된 경우
• 다국어·대소문자·정규화 처리
• DB 연결 지연 또는 타임아웃
• rows가 빈 배열인 경우
• 이름이나 이메일이 NULL인 경우
• 전화번호 등 민감정보의 로그 유출
• 응답 데이터가 지나치게 큰 경우

6. 리팩터링 로드맵

반드시 수정

1. SQL 파라미터 바인딩 적용
2. 관리자 인증 및 권한 확인
3. q 입력값 검증 및 최대 길이 설정
4. DB 오류 시 즉시 500 응답
5. 결과 개수 제한 및 페이지네이션 추가
6. 반환 개인정보 최소화 또는 마스킹
7. 감사 로그와 접근 로그 추가

권장 수정

• 검색 로직을 서비스 또는 저장소 계층으로 분리
• 요청 스키마 검증 라이브러리 적용
• 구조화된 로거 사용
• DB 쿼리 타임아웃 설정
• 검색어가 없을 때 전체 조회를 금지
• 대규모 데이터라면 전문 검색 인덱스나 별도 검색 솔루션 검토

개선 예시

app.get(
  '/admin/users/search',
  requireAdmin,
  async (req, res, next) => {
    try {
      const q = typeof req.query.q === 'string'
        ? req.query.q.trim()
        : '';

      if (q.length < 2 || q.length > 100) {
        return res.status(400).json({
          error: '검색어는 2~100자여야 합니다.'
        });
      }

      const pattern = `%${q}%`;
      const sql = `
        SELECT id, name, email
        FROM users
        WHERE name LIKE ? OR email LIKE ?
        ORDER BY id DESC
        LIMIT 50
      `;

      const [rows] = await db.query(sql, [pattern, pattern]);

      return res.json({
        items: rows,
        count: rows.length
      });
    } catch (err) {
      req.log?.error({ err }, 'admin user search failed');
      return next(err);
    }
  }
);

실제 DB 드라이버의 반환 형식에 따라 db.query 사용법은 조정해야 합니다.

우선순위 테스트

1. 악의적인 검색어가 SQL Injection을 일으키지 않고 정상적으로 처리되는지
2. 검색어 누락, 빈 문자열, 1자, 101자 입력 시 400을 반환하는지
3. 비관리자 요청이 401 또는 403으로 차단되는지
4. DB 오류 발생 시 500과 일반화된 오류 메시지를 반환하는지
5. 결과가 최대 페이지 크기를 초과하지 않는지

결론적으로, 이 코드는 기능 시연 수준이며 현재 형태로는 배포하면 안 됩니다. SQL 파라미터 바인딩과 관리자 권한 검증을 최우선으로 수정해야 합니다.