[개발 일기] 2025.03.20 - 에러 로그를 찍어도 되나? (Feat : 시큐어 코딩)

💡 개요

 

OKKY에선 예외가 발생하면 해당 예외에 대한 로그를 찍으면 되냐 안 되냐 시큐어 코딩 위반이냐 아니냐에 대해 이야기하는 것을 봤다.

 

 

오늘은 에러 로그를 찍는게 맞는지 아닌지 정리해 보자.

 

 

 

📕 시큐어 코딩

 

시큐어 코딩이란 ‘사용자가 입력한 데이터는 신뢰할 수 있는 데이터가 아니다’라는 전제를 기반으로 코드를 작성하는 것이다.

 

 

🛠️ 시큐어 코딩 점검 항목

 

• 입력 데이터 검증 및 표현
  • 사용자의 입력값을 검증하여 SQL Injection, XSS, CSRF을 방지한다.
  • 예: 사용자 입력값을 검증하고, SQL 쿼리 실행 전에 바인딩 처리하여 실행
    
    
• 보안 기능
  • 인증, 접근 제어, 암호화 등을 적절히 적용하여 보안 기능을 강화해야 한다.
  • 예: 비밀번호를 평문으로 저장하지 않고, 해시 함수(예: bcrypt)로 암호화
    
    
• 시간 및 상태
  • 경쟁 조건(Race Condition), 세션 관리 미흡 등의 문제를 방지해야 한다.
  • 예: 멀티스레드 환경에서 동기화 처리, 세션 타임아웃 설정
    
    
• 에러 처리
  • 오류 메시지에 민감한 정보(예: 스택 트레이스, DB 정보 등)가 노출되지 않도록 처리해야 한다.
  • 예: 예외 발생 시 사용자에게는 일반적인 오류 메시지만 노출
    
    
• 코드 오류
  • 메모리 누수, NullPointerException, 논리 오류 등으로 인해 보안 취약점이 발생하지 않도록 주의해야 한다.
  • 예: try-catch-finally를 활용하여 자원 해제, 정적 코드 분석 도구 사용
    
    
• 캡슐화
  • 중요 데이터를 안전하게 보호하고, 불필요한 정보 노출을 방지해야 한다.
  • 예: 중요 정보(예: 계정 정보)를 외부에서 직접 접근할 수 없도록 private 필드로 선언
    
    
• API 오용
  • 잘못된 API 사용으로 인한 보안 취약점을 예방해야 한다.
  • 예: 보안이 취약한 암호화 알고리즘 사용 금지(MD5, SHA-1 대신 SHA-256 이상 사용)
    
    

위 7가지 점검 항목 중 우리가 주목해야 할 것은 에러 처리이다.

 

 

 

🛠️ 에러 처리와 시큐어 코딩

 

시큐어 코딩의 에러 처리 항목을 보면, "서버 내부에서 발생한 에러 로그를 찍어선 안 된다"라고 표현되어 있다.

 

 

하지만 나는 이 의견에 적극적으로 찬성하기 어렵다.

 

 

물론 클라이언트에게 에러 응답을 보낼 때, 지나치게 상세한 에러 사유를 제공하는 것은 보안상 위험할 수 있다는 점에 동의한다.

 

 

내부 시스템의 구조나 데이터베이스 관련 정보를 그대로 노출하는 것은 해킹의 단서가 될 수 있기 때문이다.

 

 

그러나 서버 내부에서조차 에러 로그를 남기지 말아야 한다는 주장에는 동의하기 어렵다.

 

 

왜냐하면 에러 로그가 개발자에게 주는 이점이 매우 크기 때문이다.

 

 

대표적인 예가 디버깅이다.

 

 

에러가 발생했다는 사실 자체는 누구나 알 수 있다.

 

 

하지만 진짜 어려운 것은 그 에러가 정확히 어디에서, 왜 발생했는지를 찾아내는 것이다. 에러 로그는 이러한 과정에서 중요한 단서를 제공한다.

 

 

실제로 많은 서비스에서도 내부 로그를 필수적으로 남기고 있으며, 이를 통해 문제 발생 시 신속하게 원인을 분석하고 해결할 수 있다.

 

 

그리고 이미 서버 내부 로그를 열람할 수 있는 상태라면, 공격자(해커)는 단순히 로그를 보는 것에서 끝나지 않는다.

 

 

그 시점에서 공격자의 목표는 로그가 아니라, 훨씬 더 중요한 데이터베이스나 시스템 주요 정보일 가능성이 크다.

 

 

즉, 로그 자체가 보안 문제의 본질이 아니다.

 

 

진짜 중요한 것은 로그를 어떻게 관리하느냐이다.

 

 

 

👨🏻‍💻 참고

예외를 씹지 말자. 예외를 씹지 말자… | OKKY